K8s安全实践：使用ServiceAccount为应用程序授权

对用户授权访问K8s (TLS证书)

如何对用户授权访问Kubernetes集群的示例配置：

1. 角色权限分配：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     namespace: default
     name: pod-reader
   rules:
   - apiGroups: [ "" ] # 核心API组，例如namespace, pod, service等
     resources: [ "pods" ] # 资源名称（复数），例如pods, deployments, services
     verbs: [ "get", "watch", "list" ] # 资源操作方法

2. 将主体与角色绑定：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: read-pods
     namespace: default
   subjects:
   - kind: User
     name: jane # 主体名称
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: Role
     name: pod-reader # 角色名称
     apiGroup: rbac.authorization.k8s.io

基于角色的权限访问控制：RBAC

RBAC在Kubernetes中的基本概念和实现：

• RBAC（基于角色的访问控制）：

  • Kubernetes的默认授权策略，动态配置策略（修改即时生效）。

• 主体（subject）：

  • User（用户）
  • Group（用户组）
  • ServiceAccount（服务账号）

• 角色（role）：

  • Role：授权特定命名空间的访问权限
  • ClusterRole：授权所有命名空间的访问权限

• 角色绑定：

  • RoleBinding：将角色绑定到主体
  • ClusterRoleBinding：将集群角色绑定到主体

通过RBAC可以实现对不同用户或服务账号的精细化权限控制。

对用户授权访问K8s (TLS证书)

如何为用户组授权访问K8s的步骤：

1. 用户组的好处：

   • 无需单独为某个用户创建权限，统一为这个组名进行授权，所有的用户都可以以组的身份访问资源。

2. 为dev用户组统一授权：

   • 修改certs.sh文件中的alilang-csr.json下的O字段改为dev，并重新生成证书和kubeconfig文件。
   • 将dev用户组绑定至Role（pod-reader）。
   • 测试：只要O字段都是dev，这些用户持有的kubeconfig文件都拥有相同的权限。

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

对应用程序授权访问K8s (ServiceAccount)

如何对应用程序授权访问K8s API的服务账号：

• ServiceAccount（服务账号，简称SA）：

  • 用于让程序访问K8s API的服务账号。

• SA的创建和使用：

  • 当创建namespace时，会自动创建一个名为default的SA，这个SA没有绑定任何权限。
  • 当default SA创建时，会自动创建一个default-token-xxx的secret，并自动关联到SA。
  • 当创建Pod时，如果没有指定SA，会自动为Pod以volume方式挂载这个default SA，在容器目录：/var/run/secrets/kubernetes.io/serviceaccount。

• 验证默认SA权限：

  kubectl --as=system:serviceaccount:default:default get pods

本文由mdnice多平台发布