Kubernetes（k8s）的授权（Authorization）策略决定了已经通过认证的用户或服务账户可以访问哪些资源以及可以执行哪些操作。Kubernetes主要支持以下几种授权模式：
-
Role-Based Access Control (RBAC):
- Kubernetes中最常用的授权模型，基于角色分配权限。它允许管理员创建角色（Roles或ClusterRoles），并将其绑定到用户或服务账户（通过RoleBindings或ClusterRoleBindings）。
- 角色定义了一组权限，比如读取Pods、修改Deployments等。
- 示例RBAC配置创建一个只读角色：
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: read-only rules: - apiGroups: [""] resources: ["pods", "services"] verbs: ["get", "list", "watch"]
-
Attribute-Based Access Control (ABAC):
- 基于属性的访问控制，通过静态策略文件定义，这些策略基于用户、组、命名空间、资源类型等属性。
- ABAC较为灵活，但管理复杂度较高，且不如RBAC普及。
- ABAC策略示例不在YAML中配置，而是通过API Server的
--authorization-policy-file参数指定的JSON或CSV文件定义。
-
Webhook Authorization:
- 使用远程HTTP服务（Webhook）进行授权决策。Webhook接收API请求的相关信息，并返回是否允许该请求的决策。
- 适合需要动态或复杂逻辑的授权决策场景，如集成外部IAM系统。
- 配置示例涉及API Server启动参数
--authorization-webhook-config-file指向包含Webhook配置的文件。
-
AlwaysDeny / AlwaysAllow:
- 测试或特殊场景下使用。AlwaysDeny拒绝所有请求，AlwaysAllow则允许所有请求。
- 这些模式不常用于生产环境，因为它们提供了最极端的安全策略。
在实际应用中，通常推荐使用RBAC，因为它提供了细粒度的权限控制且易于管理。配置文件中的授权模式通过API Server启动参数--authorization-mode指定，可以组合使用多种模式，如--authorization-mode=RBAC,Webhook。在多种模式并存时，只要有任何一种模式允许访问，请求就被认为是授权通过；如果所有模式都拒绝访问，则请求被拒绝。
