k8s 的认证机制是啥？
说到 k8s 的认证机制，其实之前咋那么也有提到过 ServiceAccouont ，以及相应的 token ，证书 crt，和基于 HTTP 的认证等等
k8s 会使用如上几种方式来获取客户端身份信息，不限于上面几种
前面有说到 ApiServer 收到请求后，会去校验客户端是否有权限访问，ApiServer 会去自身的认证插件中进行处理认证，进而到授权插件中进行授权，例如这样的：
ServiceAccount 相当重要，之前我们说到过访问 pod 元数据的时候，就提到过 ServiceAccount**，以及相应的挂载文件：**
- /var/run/secrets/kubernetes.io/serviceaccount/token
- /var/run/secrets/kubernetes.io/serviceaccount/namespace
- /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
pod 就是通过发送上述的 token 文件来进行身份认证的，这是代表了运行的 pod 中的应用程序的身份证明，每一个 pod 都是会有一个 ServiceAccoount 与之关联的
我们可以理解 ServiceAccoount 不是什么也别的东西，也是 k8s 的其中一种资源而已，咱们可以写 yaml 创建该 资源，当然也是可以通过命令来创建 sa 资源的， sa 是 ServiceAccoount 的缩写
例如，我们可以通过命令 kubectl get sa 来查看 ServiceAccoount
一个 pod 只会对应一个 SA，但是 一个 SA 是可以和多个 pod 关联的，并且，我们需要清楚，这些都是得再同一个命名空间下的，例如画一个简图来是表示一下
我们可以看到，同一个命名空间中
- 一个 SA 可以对应多个 pod
- 一个 ns （namespace） 中可以有多个 ServiceAccount
- 一个 pod 只能关联 一个 ServiceAccount
再来看看这个：
绝对不会存在 ns 4 的 pod ，会关联到 ns 3 的 ServiceAccount， 不在同一个命名空间，根本无法操作
自行创建一个 SA
kubectl create sa xmt
创建一个 SA 名为 xmt
查看上述 xmt SA 的信息，k8s 默认给我们 xmt 账户生成了 token 和 secrets
我们可以查看 secrets 的内容
我们可以通过在线的 jwt 解码工具来查看这个 secrets，他是一个 JWT 编码的信息
https://tooltt.com/jwt-decode/
我们解码后，可以看到具体的信息
{ "iss": "kubernetes/serviceaccount", "kubernetes.io/serviceaccount/namespace": "default", "kubernetes.io/serviceaccount/secret.name": "xmt-token-kbv8b", "kubernetes.io/serviceaccount/service-account.name": "xmt", "kubernetes.io/serviceaccount/service-account.uid": "587fbca5-f20c-4421-a3fd-db21b76c7ac6", "sub": "system:serviceaccount:default:xmt" }
通过上述 secrets 可以得到 namespace，secret.name，service-account.name，service-account.uid 等信息 ，这个 uid 是唯一的
创建 pod 指定 SA
我们可以查看任意一个 pod 的详情，也可以看到配置里面有 ServiceName
今天就到这里，学习所得，若有偏差，还请斧正
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
更多的可以查看 零声每晚八点直播：https://ke.qq.com/course/417774
