示例 1: 开发人员对特定命名空间的只读访问#

{
  "user": "developer",
  "namespace": "development",
  "resource": ["pods", "services", "configmaps"],
  "readonly": true
}

示例 2: 管理员对所有资源的完全访问#

{
  "user": "admin",
  "namespace": "*",
  "resource": "*",
  "readonly": false
}

示例 3: 审计用户只能查看日志#

{
  "user": "auditor",
  "namespace": "*",
  "resource": ["events", "pods/log"],
  "readonly": true
}

示例 4: 限制用户只能访问特定资源种类#

{
  "user": "tester",
  "namespace": "test",
  "resource": ["pods"],
  "readonly": false
}

示例 5: 服务账户的自定义权限#

{
  "user": "system:serviceaccount:default:my-service-account",
  "namespace": "production",
  "resource": ["secrets"],
  "readonly": true
}

注意事项：

1. ABAC 的规则匹配是线性扫描，顺序非常重要。
2. 当规则复杂时，可能导致配置难以维护，因此 Kubernetes 推荐使用 RBAC。

优点：

• 灵活，可以为不同用户和操作设置精细规则。

缺点：

• 不易维护，尤其在大规模集群中。
• 动态性较差，需要修改文件并重启 API Server。

示例 1: 为开发人员赋予查看 Pod 的权限#

kubectl create role pod-viewer --verbs=get --verbs=list --verbs=watch\
--resource=pods --resource-name=podName1 --resource-name=podName2\
--namespace development

kubectl create rolebinding pod-viewer-binding --role=pod-viewer --user=developer 

kubectl create role pod-viewer \
  --verb=get,list,watch \
  --resource=pods \
  --resource-name=podName1 \
  --resource-name=podName2 \
  --namespace=development
  
kubectl create rolebinding pod-viewer-binding \
  --role=pod-viewer \
  --user=developer \
  --namespace=development

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-viewer
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
  resourceName: ["podName1", "podName2"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-viewer-binding
  namespace: development
subjects:
- kind: User
  name: developer
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-viewer
  apiGroup: rbac.authorization.k8s.io

示例 2: 为集群管理员赋予全局权限#

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: User
  name: admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

示例 3: 为 [[ServiceAccount]] 赋予权限

apiVersion: v1
kind: ServiceAccount
metadata:
  name: service-account-name
  namespace: service-account-namespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: admin
  namespace: service-account-namespace
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: ServiceAccount
  name: service-account-name
  namespace: service-account-namespace
roleRef:
  kind: CRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

RBAC 动态性示例#

• RBAC 配置支持动态修改，无需重启 API Server。
• 例如，在生产环境中临时授予用户权限，可以直接创建或删除 RoleBinding。

优点：

• 动态配置，无需重启 API Server。
• 维护性强，适合大规模集群。

Open Policy Agent (OPA) 简介#

OPA 是一个通用策略引擎，可用于授权决策。通过 Webhook，Kubernetes 的授权请求可以由 OPA 接管，实现高度定制化的策略管理。

基本架构#

1. API Server：将授权请求发送到 OPA Webhook。
2. OPA Server：根据预定义的策略决定请求是否允许。
3. Rego 语言：用于编写 OPA 的策略。

配置 OPA Webhook#

1. 部署 OPA：

   • 部署 OPA 容器以拦截 API Server 请求。
   • 使用 ConfigMap 存储策略。

2. 配置 API Server：

apiVersion: apiserver.k8s.io/v1
kind: WebhookConfiguration
metadata:
  name: opa-webhook
webhooks:
  - name: opa.authorization.k8s.io
    clientConfig:
      service:
        name: opa
        namespace: opa
        path: "/v1/data/authorization/allow"
    rules:
    - apiGroups: ["*"]
      apiVersions: ["*"]
      resources: ["*"]

3. 编写 Rego 策略：
   策略存储于 allow.rego 文件中，例如：

package authorization

default allow = false

allow {
  input.review.request.user == "admin"
  input.review.request.namespace == "development"
}

4. 测试策略：

• 使用 kubectl auth can-i 验证用户权限。
• 检查 OPA 日志以调试策略行为。