一，ABAC授权模式

Kubernetes ABAC（Attribute-Based Access Control）授权模式是一种基于属性的访问控制模型，它可以根据用户或组的属性决定是否允许他们访问 Kubernetes 集群中的资源。

在使用 ABAC 授权模式时，管理员需要定义一些规则来限制哪些用户或组有权访问集群中的不同资源。这些规则通常包括一个或多个属性和一个操作，如“查看”、“创建”、“修改”或“删除”。

下面是一些示例规则：

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1","kind": "Policy","spec": {"user": "admin","namespace": "*","resource": "*","readonly": true}
}

这个示例规则表示只有 admin 用户能够读取任何命名空间下的所有资源。

要启用 ABAC 授权模式，管理员必须在 kube-apiserver 的启动参数中添加 --authorization-mode=ABAC，并指定存储策略文件路径（通过 --authorization-policy-file 选项）。另外，还需在 kubelet 的启动参数中添加 --authorization-mode=ABAC 选项。

需要注意的是，在 Kubernetes v1.19 版本之后，已经弃用了 ABAC 授权模式，并且在将来的版本中将被移除。建议使用更安全、更灵活的 RBAC （Role-Based Access Control）或其他授权模式。

二，Webhook授权模式

Kubernetes Webhook 授权模式是一种基于 HTTP 回调的访问控制模型，它可以通过向外部 Web 服务发送请求来判断用户是否有权限访问 Kubernetes 集群中的资源。

在使用 Webhook 授权模式时，管理员需要定义一个 HTTP 回调 URL，然后将该 URL 注册到 Kubernetes API Server 中。当用户发起请求时，API Server 会将请求信息发送到该 URL 上，并等待一个命名为 "status" 的 JSON 对象作为响应。

Webhook 授权模式中的回调服务可以进行各种自定义逻辑来决定用户是否有权限访问集群中的资源。例如，它可以查询 LDAP 或 Active Directory 来获取用户组成员身份、检查 JWT token 签名或者从 RBAC 角色映射文件中读取策略。

下面是一个示例 webhook 配置：

apiVersion: v1
kind: ConfigMap
metadata:name: my-auth-config
data:authz.yaml: |clusterName: my-k8s-clusterendpoint: https://my-webhook-service-endpoint.com/authz-check

这个配置表明了 webhook 认证所需要的参数：集群名称和认证服务端点 URL。

要启用 Webhook 授权模式，管理员需要在 kube-apiserver 的启动参数中添加 --authorization-mode=Webhook，并指定配置文件路径（通过 --authorization-webhook-config-file 选项）。另外还需启动 webhook 容器并监听 API 请求。

三，RBAC授权模式

Kubernetes RBAC (Role-Based Access Control) 授权模式是一种基于角色和权限的访问控制模型，它可以对 Kubernetes 集群中的资源进行精细化的授权管理。

在使用 RBAC 授权模式时，管理员需要定义三种类型的对象：

1. Role：角色，用来定义一组权限；
2. RoleBinding：角色绑定，将一个角色与一个用户或用户组关联起来；
3. ClusterRole：集群级别的角色，用来定义一组跨命名空间的权限；

然后就可以通过 Kubernetes API 来创建、更新和删除这些对象。例如，下面是一个简单的 RBAC 示例：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:namespace: defaultname: pod-reader
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "watch", "list"]---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:name: read-podsnamespace: default
subjects:
- kind: User # 用户类型为 User 或 Group name: test-user # 要授权的用户名或用户组名 
roleRef:kind: Role # 角色类型为 Role 或 ClusterRole name: pod-reader # 要绑定到的角色名称 apiGroup: rbac.authorization.k8s.io

这个例子中创建了一个 PodReader 的角色，并将其绑定到了 test-user 用户上。该角色的权限是只读访问 Pods 资源，而且这个角色只能在 default 命名空间中使用。

要启用 RBAC 授权模式，管理员需要在 kube-apiserver 的启动参数中添加 --authorization-mode=RBAC。如果你使用的是 Kubernetes v1.6 及以上版本，则该参数默认已开启。

四，Pod的安全策略配置

Kubernetes 的 Pod 安全策略可以帮助我们提高集群的安全性。以下是一些常见的 Pod 安全策略配置：

1. 禁止特权容器：特权容器是具有 Linux 的 root 权限和访问主机名字空间、网络名字空间等权限的容器。禁止使用特权容器可以有效地避免攻击者利用容器逃脱沙盒。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:name: restrict-privilege
spec:privileged: falseallowPrivilegeEscalation: false

1. 文件系统只读：将文件系统设置为只读，可以防止攻击者在运行时修改敏感信息或植入木马。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:name: readonly-fs
spec:volumes:- configMap- downwardAPI- emptyDir- persistentVolumeClaim- projected - secret fsGroup:rule: RunAsAny # 继承宿主机用户组 runAsUser:rule: RunAsAny # 继承宿主机用户 seLinux:rule: RunAsAny # 继承宿主机 SELinux 标签 supplementalGroups:rule: MustRunAs # 必须以指定用户组运行 

1. AppArmor 或 Seccomp：AppArmor 和 Seccomp 是两种 Linux 安全模块，它们可以限制容器的系统调用和文件系统访问权限。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:name: restrict-apparmor-seccomp
spec:seLinux:rule: RunAsAny # 继承宿主机 SELinux 标签 supplementalGroups:rule: MustRunAs # 必须以指定用户组运行 volumes:- configMap- downwardAPI- emptyDir- persistentVolumeClaim allowedUnsafeSysctls:- "kernel.msg*"forbiddenSysctls:- "net.ipv4.ip_forward"

在配置完 Pod 安全策略后，需要创建一个 ClusterRoleBinding 对象来将该安全策略绑定到 ServiceAccount 上：

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:name: psp-admin-binding
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRole name: psp-admin 
subjects:
- kind: ServiceAccount name: default namespace: default

这个例子中创建了一个名为 restrict-privilege 的 PodSecurityPolicy，并将其绑定到了默认的 ServiceAccount 上。这样，在使用该 ServiceAccount 创建 Pod 或 Deployment 时，就会自动应用这个安全策略。