k8s--基础--23.2--认证-授权-准入控制--认证

k8s–基础–23.2–认证-授权-准入控制–认证

---

1、介绍

1.1、kubernetes上的账号

客户端对apiserver发起请求，apiserver要识别这个用户是否有请求的权限，要识别用户本身能否通过apiserver执行相应的操作，那么需要哪些信息才能识别用户信息来完成对用户的相关的访问控制呢？

kubectl explain pods.spec.serviceAccountName(服务账号名称)，这个就是我们pod连接apiserver时使用的账号，因此整个kubernetes集群中的账号有两类
1. ServiceAccount(服务账号)
2. User account(linux用户账号)

1.2、User account

1. 用户登陆的账号，客户端想要对apiserver发起请求，apiserver要识别这个客户端是否有请求的权限，那么不同的用户就会有不同的权限，靠用户账号表示，叫做username
2. user account：这个是登陆k8s物理机器的用户

1.3、ServiceAccount(sa)

1. 用于Pod里面的进程调用Kubernetes API或其他外部服务
2. 是kubernetes中的一种资源
3. sa账号：登陆dashboard使用的账号

1.4、ServiceAccount和User account区别

1. User account是为人设计的，而service account则是为Pod中的进程调用Kubernetes API而设计。
2. User account是跨namespace的，而service account则是仅局限它所在的namespace
   1. 每个namespace都会自动创建一个default service account；

1.5、认证流程

kubectl客户端拿着token进行认证，然后把请求发送给https协议

2、ServiceAccount

2.1、开启ServiceAccount Admission Controller后

1. 每个Pod在创建后都会自动设置spec.serviceAccount为default(除非指定了其他ServiceAccout)
2. 验证Pod引用的service account已经存在，否则拒绝创建；
3. 如果Pod没有指定ImagePullSecrets，则把service account的ImagePullSecrets加到Pod中。

2.2、自动设置serviceaccount为default

1. 当创建 pod 的时候，如果没有指定一个 serviceaccount，系统会自动在与该pod 相同的 namespace 下为其指派一个default service account。
2. pod和apiserver之间进行通信的账号，称为serviceAccountName

2.2.1、配置

vi  /root/test5/pod_nginx.yaml

内容

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: default
  labels:
    la: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

2.2.2、执行

kubectl apply -f /root/test5/pod_nginx.yaml

2.2.3、分析

kubectl get pods

kubectl get pods nginx -o yaml | grep "serviceAccountName"

kubectl describe pods nginx

从上面可以看到每个Pod无论定义与否都会有个存储卷，这个存储卷为default-token-*的 token令牌，这就是pod和serviceaccount认证信息。

通过secret进行定义，由于认证信息属于敏感信息，所以需要保存在secret资源当中，并以存储卷的方式挂载到Pod当中。从而让Pod内运行的应用通过对应的secret中的信息来连接apiserver，并完成认证。

每个 namespace 中都有一个默认的叫做 default 的 serviceaccount 资源。进行查看名称空间内的secret，也可以看到对应的default-token。让当前名称空间中所有的pod在连接apiserver时可以使用的预制认证信息，从而保证pod之间的通信。

# 查看 默认名称空间的 sa账号
kubectl get sa

# 查看 kube-system名称空间的 sa账号
kubectl get sa -n kube-system

# 查看 默认名称空间的 secret
kubectl get secret

# 查看 kube-system名称空间的  secret
kubectl get secret -n kube-system

2.3、创建一个serviceaccount

默认的service account 仅仅只能获取当前Pod自身的相关属性，无法观察到其他名称空间Pod的相关属性信息。如果想要扩展Pod，假设有一个Pod需要用于管理其他Pod或者是其他资源对象，是无法通过自身的名称空间的serviceaccount进行获取其他Pod的相关属性信息的，此时就需要进行手动创建一个serviceaccount，并在创建Pod时进行定义。

serviceAccount属于标准的k8s资源，可以创建一个serviceAccount，创建之后由我们创建的pod使用serviceAccountName去加载自己定义的serviceAccount就可以了

2.3.1、创建一个serviceaccount

kubectl create serviceaccount test
kubectl get sa

可以看到已经创建了test的serviceacount

2.3.2、分析

#  查看test这个账号的详细信息
kubectl describe sa test

上面可以看到生成了一个test-token-ptm4d的secret和test-token-ptm4d的token

kubectl get secret  

kubectl describe secret test-token-ptm4d 

上面可以看到生成了test-token-ptm4d的token详细信息，这个账号就是sa连接apiserver的账号，这个token是登陆k8s的token，这些是一个认证信息，能够登陆k8s，能认证到k8s，但是不能做别的事情，不代表权限，想要做其他事情，需要授权

2.4、kubeconfig文件

在K8S集群当中，每一个用户对资源的访问都是需要通过apiserver进行通信认证才能进行访问的，那么在此机制当中，对资源的访问可以是token，也可以是通过配置文件的方式进行保存和使用认证信息。

2.4.1、

通过kubectl config进行查看配置

kubectl config view

内容

apiVersion: v1
# 集群列表
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    # 集群服务的地址，就是apiserver的地址，或者说master1的地址
    server: https://192.168.187.154:6443
  # 集群的名称，上下文有使用到
  name: kubernetes
# k8s上下文
contexts:
- context:
    # 上下文的集群
    cluster: kubernetes
    # 表示用户kubernetes-admin可以访问集群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

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