认证

1.认证基本介绍：kubernetes主要通过APIserver对外提供服务，那么就需要对访问apiserver的用户做认证，如果任何人都能访问apiserver，那么就可以随意在k8s集群部署资源，这是非常危险的，也容易被黑客攻击渗透，所以需要我们对访问k8s系统的apiserver的用户进行认证，确保是合法的符合要求的用户。 2.授权基本介绍：认证通过后仅代表它是一个被apiserver信任的用户，能访问apiserver，但是用户是否拥有删除资源的权限， 需要进行授权操作，常见的授权方式有rbac授权。 3.准入控制基本介绍：当用户经过认证和授权之后，最后一步就是准入控制了，k8s提供了多种准入控制机制，它有点类似"插件"，为apiserver提供了很好的"可扩展性"。请求apiserver时，通过认证、鉴权后、持久化(“api对象"保存到etcd)前，会经过"准入控制器”，让它可以做"变更和验证"

访问apiserver的几种认证方式

客户端认证

客户端认证也称为双向TLS认证， kubectl在访问apiserver的时候，apiserver也要认证kubectl是否是合法的，他们都会通过ca根证书来进行验证，如下图：

image-20250502152137098

Bearertoken

Bearertoken的方式，可以理解为apiserver将一个密码通过了非对称加密的方式告诉了kubectl，然后通过该密码进行相互访问，如下图：

image-20250502152159721

Kubectl访问k8s集群，要找一个kubeconfig文件，基于kubeconfig文件里的用户访问apiserver

Serviceaccount

上面客户端证书认证和Bearertoken的两种认证方式，都是外部访问apiserver的时候使用的方式，那么我们这次说的Serviceaccount是内部访问pod和apiserver交互时候采用的一种方式。Serviceaccount包括了，namespace、token、ca，且通过目录挂载的方式给予pod，当pod运行起来的时候，就会读取到这些信息，从而使用该方式和apiserver进行通信。如下图：

image-20250502152248833

kubeconfig文件

在K8S集群当中，当我们使用kubectl操作k8s资源时候，需要确定我们用哪个用户访问哪个k8s集群，kubectl操作k8s集群资源会去/root/.kube目录下找config文件，可以通过kubectl config查看config文件配置，如下

kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.40.180:6443     #apiserver的地址
  name: kubernetes                         #集群的名字
contexts:
- context:
    cluster: kubernetes                     
    user: kubernetes-admin   
  name: kubernetes-admin@kubernetes     #上下文的名字
current-context: kubernetes-admin@kubernetes       #当前上下文的名字
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

在上面的配置文件当中，定义了集群、上下文以及用户。其中Config也是K8S的标准资源之一，在该配置文件当中定义了一个集群列表，指定的集群可以有多个；用户列表也可以有多个，指明集群中的用户；而在上下文列表当中，是进行定义可以使用哪个用户对哪个集群进行访问，以及当前使用的上下文是什么。授权

授权

用户通过认证之后，什么权限都没有，需要一些后续的授权操作，如对资源的增删该查等，kubernetes1.6之后开始有RBAC（基于角色的访问控制机制）授权检查机制。

RBAC（基于角色的授权）

让一个用户（Users）扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制。如图：

image-20250502152412911

在k8s的授权机制当中，采用RBAC的方式进行授权，其工作逻辑是，把对对象的操作权限定义到一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限。如果通过rolebinding绑定role，只能对rolebingding所在的名称空间的资源有权限，上图user1这个用户绑定到role1上，只对role1这个名称空间的资源有权限，对其他名称空间资源没有权限，属于名称空间级别的； 另外，k8s为此还有一种集群级别的授权机制，就是定义一个集群角色（ClusterRole），对集群内的所有资源都有可操作的权限，从而将User2通过ClusterRoleBinding到ClusterRole，从而使User2拥有集群的操作权限。

Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系

用户基于rolebinding绑定到role

限定在rolebinding所在的名称空间

image-20250502152449480

用户基于rolebinding绑定到clusterrole

image-20250502152512096

rolebinding绑定clusterrole的优点：

假如有6个名称空间，每个名称空间的用户都需要对自己的名称空间有管理员权限，那么需要定义6个role和rolebinding，然后依次绑定，如果名称空间更多，我们需要定义更多的role，这个是很麻烦的，所以我们引入clusterrole，定义一个clusterrole，对clusterrole授予所有权限，然后用户通过rolebinding绑定到clusterrole，就会拥有自己名称空间的管理员权限了 注：RoleBinding仅仅对当前名称空间有对应的权限。

用户基于clusterrolebinding绑定到clusterrole

image-20250502152600557

准入控制

在k8s上准入控制器的模块有很多，其中比较常用的有LimitRanger、ResourceQuota、ServiceAccount、PodSecurityPolicy(k8s1.25废弃了)等等，对于前面三种准入控制器系统默认是启用的，我们只需要定义对应的规则即可；对于PodSecurityPolicy(k8s1.25废弃了)这种准入控制器，系统默认没有启用，如果我们要使用，就必需启用以后，对应规则才会正常生效；这里需要注意一点，对应psp准入控制器，一定要先写好对应的规则，把规则和权限绑定好以后，在启用对应的准入控制器，否则先启用准入控制器，没有对应的规则，默认情况它是拒绝操作，这可能导致现有的k8s系统跑的系统级pod无法正常工作；所以对于psp准入控制器要慎用，如果规则和权限做的足够精细，它会给我们的k8s系统安全带来大幅度的提升，反之，可能导致整个k8s系统不可用。

Useraccount和ServiceAccount介绍

kubernetes中账户分为：UserAccounts（用户账户） 和 ServiceAccounts（服务账户） 两种：

1.UserAccount是给kubernetes集群外部用户使用的，如kubectl访问k8s集群要用useraccount用户， kubeadm安装的k8s，默认的useraccount用户是kubernetes-admin； 2.k8s客户端(一般用:kubectl) ------>API Server

3.APIServer需要对客户端做认证，使用kubeadm安装的K8s，会在用户家目录下创建一个认证配置文件 .kube/config 这里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。

用户名称可以在kubeconfig中查看

cd ~/.kube/
ls
cache config http-cache
cat config

users:
- name: kubernetes-admin

ServiceAccount是Pod使用的账号，Pod容器的进程需要访问API Server时用的就是ServiceAccount账户；ServiceAccount仅局限它所在的namespace，每个namespace创建时都会自动创建一个default service account；创建Pod时，如果没有指定Service Account，Pod则会使用default Service Account。

ServiceAccount使用案例

kubectl create sa sa-test
kubectl create clusterrolebinding sa-test-admin --clusterrole=cluster-admin  --serviceaccount=default:sa-test

results matching ""

    No results matching ""