k8s 访问控制

• 访问控制

外部用户要操作集群资源对象时，需要经历：用户认证-->授权检查-->级联检查

认证检查：token，ssl 。。。

授权检查：ABAC，RBAC，webHook。。。

API server是操作集群的唯一入口，apiserver又是一个restful风格的应用 程序，所以所有请求都是通过http方式发往apiserver的。访问路径为

/apis/<GROUP>/<VERSION>/namespaces/<NAMESPACE_NAME>/<KIND>[/OBJECT_ID]/

apiserver监听的端口为6443，为https协议，访问需要认证，kubectl不需要认证是因为在~/.kube/config文件中保存有认证信息

apiserver可以接收的请求动作有：get，list，create，update，patch，watch，proxy，redirect，delete，deletecollection

• userAccount和serviceAccoun

所有的 Kubernetes 集群都有两类用户：Kubernetes 管理的serviceAccount和userAccount。

userAccount由 Kubernetes 集群之外的独立服务管理，例如 keycloak、LDAP、OpenID Connect Identity Provider（Google Account、MicroSoft Account、GitLab Account）等。此类服务对用户的注册、分组、密码更改、密码策略、用户失效策略等有一系列管控过程，或者，也可以简单到只是一个存储了用户名密码的文件。Kubernetes 中，没有任何对象用于代表普通的用户账号，普通用户也不能通过 API 调用添加到 Kubernetes 集群。

与userAccount相对，serviceAccount是通过 Kubernetes API 管理的用户。serviceAccount是名称空间级别的对象，可能由 ApiServer 自动创建，或者通过调用 API 接口创建。serviceAccount都绑定了一组 Secret，Secret 可以被挂载到 Pod 中，以便 Pod 中的进程可以获得调用 Kubernetes API 的权限。

Kubernetes 区分userAccount和serviceAccount的概念主要基于以下原因：

• userAccount是针对人而言的。 serviceAccount是针对运行在 pod 中的进程而言的。
• userAccount是全局性的。 其名称在集群各 namespace 中都是全局唯一的，未来的用户资源不会做 namespace 隔离，serviceAccount是 namespace 隔离的。
• 通常情况下，集群的userAccount可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。 serviceAccount创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。
• 对人员和服务账户审计所考虑的因素可能不同。
• 针对复杂系统的配置可能包含系统组件相关的各种服务账户的定义。 因为服务账户可以定制化地创建，并且有 namespace 级别的名称，这种配置是很轻量的

　　创建serviceaccount会自动创建并绑定一个secret，secret中含有token信息，以实现连接apiserver时验证操作。

• RBAC

RBAC：基于角色的权限访问控制（Role-Based Access Control），用户限制用户或者serviceaccount可以查看和操作的资源范围。

在RBAC中，权限与角色相关联，用户通过扮演适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。

• Role 和 ClusterRole

　　在 RBAC API 中，一个角色包含一组相关权限的规则。权限是纯粹累加的（不存在拒绝某操作的规则）。 角色可以用 Role 来定义到某个命名空间上， 或者用 ClusterRole 来定义到整个集群作用域。

Role 只可以用来对某一命名空间中的资源赋予访问权限。

 下面的 Role 示例定义到名称为 "default" 的命名空间，可以用来授予对该命名空间中的 Pods 的读取权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 指定核心 API 组
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole 可以授予的权限和 Role 相同， 但是因为 ClusterRole 属于集群范围，所以它也可以授予以下访问权限：

• 集群范围资源 （比如 nodes）
• 非资源端点（比如 "/healthz"）
• 跨命名空间访问的有名称空间作用域的资源（如 Pods），比如运行命令kubectl get pods --all-namespaces 时需要此能力

下面的 ClusterRole 示例可用来对某特定命名空间下的 Secrets 的读取操作授权， 或者跨所有命名空间执行授权（取决于它是如何绑定的）:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # 此处的 "namespace" 被省略掉是因为 ClusterRoles 是没有命名空间的。
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

• RoleBinding 和 ClusterRoleBinding

角色绑定是将角色中定义的权限赋予一个或者一组用户。 可以使用 RoleBinding 在指定的命名空间中执行授权， 或者在集群范围的命名空间使用 ClusterRoleBinding 来执行授权。

RoleBinding 可以引用同一的命名空间中的 Role ，使所绑定的用户或者serviceaccount具有该role的权限。RoleBinding 也可以引用 ClusterRole，使所绑定的用户或者serviceaccount具有该role所在的名称空间中的clusterRole的权限。（这可以允许管理者在 整个集群中定义一组通用的角色，然后在多个命名空间中重用它们。）

ClusterRoleBinding 可用来在集群级别或对所有命名空间执行授权。

通过编辑kubeconfig文件，限制用户访问kubernetes权限

[root@master ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.103.39:6443
  name: cluster.local
contexts:
- context:
    cluster: cluster.local
    user: kubernetes-admin
  name: kubernetes-admin@cluster.local
current-context: kubernetes-admin@cluster.local
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

[root@master ~]# kubectl config -h
Modify kubeconfig files using subcommands like "kubectl config set current-context my-context"

The loading order follows these rules:

1. If the --kubeconfig flag is set, then only that file is loaded. The flag may only be set once and no merging takes
place.
2. If $KUBECONFIG environment variable is set, then it is used as a list of paths (normal path delimiting rules for
your system). These paths are merged. When a value is modified, it is modified in the file that defines the stanza. When
a value is created, it is created in the first file that exists. If no files in the chain exist, then it creates the
last file in the list.
3. Otherwise, ${HOME}/.kube/config is used and no merging takes place.

Available Commands:
current-context Displays the current-context
delete-cluster Delete the specified cluster from the kubeconfig
delete-context Delete the specified context from the kubeconfig
get-clusters Display clusters defined in the kubeconfig
get-contexts Describe one or many contexts
rename-context Renames a context from the kubeconfig file.
set Sets an individual value in a kubeconfig file
set-cluster Sets a cluster entry in kubeconfig
set-context Sets a context entry in kubeconfig
set-credentials Sets a user entry in kubeconfig
unset Unsets an individual value in a kubeconfig file
use-context Sets the current-context in a kubeconfig file
view Display merged kubeconfig settings or a specified kubeconfig file

Usage:
kubectl config SUBCOMMAND [options]

Use "kubectl <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all commands).