k8s 认证和权限控制

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 是唯一的