机制说明
Kubernetes 作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。API Server 是集群内部各个组件通信的中介，也是外部控制的入口。所以 Kubernetes 的安全机制基本就是围绕保护 API Server 来设计的。Kubernetes 使用了认证（Authentication）、鉴权（Authorization）、准入控制（Admission Control）三步来保证API Server的安全
[
- 又称3A服务
- 简单理解为认证就是检查有没有出入证，鉴权就是你能干啥，做家务还是敲代码还是做饭，准入控制就是限制那些能做但是不合理的操作,比如砸电脑，放火啥的
Authentication:认证
- HTTP Token 认证：通过一个 Token 来识别合法用户
- HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串 - Token 来表达客户的一种方式。Token 是一个很长的很复杂的字符串，每一个 Token 对应一个用户名存储在 API Server 能访问的文件中。当客户端发起 API 调用请求时，需要在 HTTP Header 里放入 Token
- HTTP Base 认证：通过 用户名+密码 的方式认证
- 用户名+：+密码 用 BASE64 算法进行编码后的字符串放在 HTTP Request 中的 Heather Authorization 域里发送给服务端，服务端收到后进行编码，获取用户名及密码
- 最严格的 HTTPS 证书认证：基于 CA 根证书签名的客户端身份认证方式
认证流程
Ⅰ、HTTPS 证书认证：
[
Ⅱ、需要认证的节点
两种类型
- Kubenetes 组件对 API Server 的访问：kubectl、Controller Manager、Scheduler、kubelet、kube-proxy
- Kubernetes 管理的 Pod 对容器的访问：Pod（dashborad 也是以 Pod 形式运行）
[
安全性说明
- Controller Manager、Scheduler 与 API Server 在同一台机器，所以直接使用 API Server 的非安全端口访问，
--insecure-bind-address=127.0.0.1 - kubectl、kubelet、kube-proxy 访问 API Server 就都需要证书进行 HTTPS 双向认证
证书颁发
- 手动签发：通过 k8s 集群的跟 ca 进行签发 HTTPS 证书
- 自动签发：kubelet 首次访问 API Server 时，使用 token 做认证，通过后，Controller Manager 会为 kubelet 生成一个证书，以后的访问都是用证书做认证了
Ⅲ、kubeconfig
kubeconfig 文件包含集群参数（CA证书、API Server地址），客户端参数（上面生成的证书和私钥），集群 context 信息（集群名称、用户名）。Kubenetes 组件通过启动时指定不同的 kubeconfig 文件可以切换到不同的集群
Ⅳ、ServiceAccount
Pod中的容器访问API Server。因为Pod的创建、销毁是动态的，所以要为它手动生成证书就不可行了。Kubenetes使用了Service Account解决Pod 访问API Server的认证问题
Ⅴ、Secret 与 SA 的关系
Kubernetes 设计了一种资源对象叫做 Secret，常用分为两类，一种是用于 ServiceAccount 的 service-account-token， 另一种是用于保存用户自定义保密信息的 Opaque [əʊˈpeɪk] 。ServiceAccount 中用到包含三个部分：Token、ca.crt、namespace
- token是使用 API Server 私钥签名的 JWT。用于访问API Server时，Server端认证
- ca.crt，根证书。用于Client端验证API Server发送的证书
- namespace, 标识这个service-account-token的作用域名空间
Json web token (JWT) , 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（[(RFC 7519] ).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该 token 也可直接被用于认证，也可被加密
kubectl get secret --all-namespaces
kubectl describe secret default-token-5gm9r --namespace=kube-system默认情况下，每个 namespace 都会有一个 ServiceAccount，如果 Pod 在创建时没有指定 ServiceAccount，就会使用 Pod 所属的 namespace 的 ServiceAccount
默认挂载目录： /run/secrets/kubernetes.io/serviceaccount/
ServiceAccount简介
流程图
什么是Service Account
- Service Account是K8s中的一个内置对象，用于为Pod提供身份认证。每个Pod都可以有一个或多个Service Account，这些Service Account由K8s API Server管理。当Pod启动时，它会自动获取一个与之关联的Service Account的令牌，这个令牌用于在Pod内部的进程尝试访问K8s API时进行身份验证。Service Account的存在使得Pod能够以受控的方式与集群的其他部分进行交互
Token和CA的定义及区别
Token和CA是两种不同的安全验证机制，它们在应用场景和实现方式上有所区别。
Token
- Token通常指的是一种短期的、临时的令牌，用于验证用户的身份、授权访问或者进行交互操作。它可以是一段随机生成的字符串或者加密后的数据，用于代表用户的身份或者权限信息。Token的作用是在用户认证通过后颁发给客户端，客户端可以在一段时间内持有并使用这个Token来访问受保护的资源。Token通常具有一定的时效性，过期后需要重新获取或刷新。
CA（证书认证机构）
- CA是数字证书认证的权威机构，负责颁发数字证书。在数字证书认证过程中，CA扮演着至关重要的角色。它通过验证和颁发数字证书，确保了网络通信的安全性和可靠性。数字证书是一种电子文档，用于证明实体身份的合法性。它包含了实体的公钥和其他相关信息，并由CA进行签名。数字证书的主要作用是确保实体身份的真实性和可信度，从而保证网络通信的安全性。
区别
- Token和CA的主要区别在于它们的使用期限和验证方式。Token是临时的，用于短期的身份验证和授权访问，而CA颁发的数字证书通常是长期有效的，用于长期的身份验证和通信加密。Token的验证通常依赖于服务器端的记录和管理，而CA证书的验证则依赖于公钥加密和数字签名技术。
总结
认证
存储 双向 HTTPS 认证 ca1
S：ETCD
C：ApiServer
服务 双向 HTTPS 认证 ca2 kubeadm 证书有效期只有一年
S：ApiServer
C：
组件
需要加密
k8s 集群自己颁发证书
kubelet
手动颁发证书或者由 kubeadm 颁发证书
kubectl
kube-proxy
他们都无法保证永远和master一直在一个节点，所以需要加密
无需加密
Controller Manager、Scheduler-
证书是由kubeadm安装工具颁发的，不是集群发的，集群只给kubelet发token，因为他在加入集群的时候就通过了双重认证
-
证书有效期只有一年，有两种解决方法，一种是更新，时间会刷新，但是有些是离线业务，不能随便更新。还有一种是更改源码，改成100年失效，第二种居多
-
一般看一下架构图，同一台机器不需要加密，不同的节点最好加密
Authorization:鉴权
上面认证过程，只是确认通信的双方都确认了对方是可信的，可以相互通信。而鉴权是确定请求方有哪些资源的权限。API Server 目前支持以下几种授权策略 （通过 API Server 的启动参数 “--authorization-mode” 设置）
- AlwaysDeny：表示拒绝所有的请求，一般用于测试
- AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略
- ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
- Webhook：通过调用外部 REST 服务对用户进行授权
- RBAC（Role-Based Access Control）：基于角色的访问控制，现行默认规则
RBAC 授权模式
RBAC（Role-Based Access Control）基于角色的访问控制，在 Kubernetes 1.5 中引入，现行版本成为默认标准。相对其它访问控制方式，拥有以下优势：
- 对集群中的资源和非资源均拥有完整的覆盖
- 整个 RBAC 完全由几个 API 对象完成，同其它 API 对象一样，可以用 kubectl 或 API 进行操作
- 可以在运行时进行调整，无需重启 API Server
什么是RBAC
-
RBAC是K8s中的一种访问控制机制，它允许管理员定义一系列的角色（Role）和集群角色（ClusterRole），并将这些角色绑定到特定的用户、组或Service Account上。每个角色定义了一组对集群资源的访问权限，包括可以执行的操作（如创建、删除、获取、列出等）。通过RBAC，可以精确控制谁可以访问哪些资源，以及他们可以执行哪些操作。
-
RBAC（基于角色的访问控制）是Kubernetes中用于管理集群权限的框架。它允许管理员定义谁可以在什么条件下访问哪些资源。RBAC通过Role和ClusterRole来定义权限集合，通过RoleBinding和ClusterRoleBinding将这些权限集合应用到具体的用户、组或ServiceAccount上
SA与RBAC的关系
-
Service Account与RBAC的关系在于，Service Account是RBAC机制中的一个实体，它通过绑定到特定的角色或集群角色来获得访问集群资源的权限。当一个Service Account被创建时，它可以被分配到一个或多个Role或ClusterRole，这样，当Pod使用这个Service Account运行时，它就会继承那些角色所定义的权限。这种方式允许管理员对Pod的权限进行精细化管理，确保Pod只能访问必要的资源，从而增强了集群的安全性。
-
总的来说，Service Account是K8s中用于身份认证的机制，而RBAC是用于授权管理的机制。通过将Service Account与RBAC相结合，K8s提供了一个强大的框架来保护集群资源免受未授权访问。
-
Service Account与RBAC机制的关联主要体现在以下几个方面：
1.身份认证与授权的桥梁：Service Account是Kubernetes中用于身份认证的机制，它为Pod提供了访问Kubernetes API的凭据。而RBAC（基于角色的访问控制）则是用于授权管理的机制，它定义了一组针对特定命名空间内资源的操作权限。Service Account通过绑定到特定的角色或集群角色，获得了访问集群资源的权限。
2.权限的细化管理：RBAC允许管理员定义不同的角色，并将这些角色赋予不同的Service Account，从而实现细粒度的权限控制。这种方式使得Pod只能访问必要的资源，增强了集群的安全性。
3.角色绑定的实现：在Kubernetes中，可以通过RoleBinding或ClusterRoleBinding将Role或ClusterRole与Service Account关联起来，使Service Account拥有了相应角色中定义的权限。这些绑定可以是命名空间级别的，也可以是集群级别的，从而控制Service Account在不同范围内的访问权限。
4.安全性的保障：通过结合Service Account和RBAC，Kubernetes提供了一个强大的框架来保护集群资源免受未授权访问。这种组合确保了只有经过适当授权的实体才能访问敏感资源，从而维护了集群的安全性
RBAC 的 API 资源对象说明
RBAC 引入了 4 个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4 种对象类型均可以通过 kubectl 与 API 操作
[
需要注意的是 Kubenetes 并不会提供用户管理，那么 User、Group、ServiceAccount 指定的用户又是从哪里来的呢？ Kubenetes 组件（kubectl、kube-proxy）或是其他自定义的用户在向 CA 申请证书时，需要提供一个证书请求文件(只要创建一个sa对象，那么他会自动创建token，ca.crt，ns)
[root@kube-master01 ~]# kubectl create sa -n default test --dry-run=client -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: null
name: test
namespace: default{
"CN": "admin",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "HangZhou",
"L": "XS",
"O": "system:masters",
"OU": "System"
}
]
}API Server会把客户端证书的CN字段作为User，把names.O字段作为Group
kubelet 使用 TLS Bootstaping 认证时，API Server 可以使用 Bootstrap Tokens 或者 Token authentication file 验证 =token，无论哪一种，Kubenetes 都会为 token 绑定一个默认的 User 和 Group
Pod使用 ServiceAccount 认证时，service-account-token 中的 JWT 会保存 User 信息
有了用户信息，再创建一对角色/角色绑定(集群角色/集群角色绑定)资源对象，就可以完成权限绑定了
如果用户，组，SA没有绑定角色，那么它的权限为0，在Kubernetes集群中，权限只能累加，从零开始一直加，没有减。声明一个有一个
Role and ClusterRole
在 RBAC API 中，Role 表示一组规则权限，权限只会增加(累加权限)，不存在一个资源一开始就有很多权限而通过 RBAC 对其进行减少的操作；Role 可以定义在一个 namespace 中，如果想要跨 namespace 则可以创建 ClusterRole
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]ClusterRole 具有与 Role 相同的权限角色控制能力，不同的是 ClusterRole 是集群级别的，ClusterRole 可以用于:
- 集群级别的资源控制( 例如 node 访问权限 )
- 非资源型 endpoints( 例如
/health访问 ) - 所有命名空间资源控制(例如 pods )
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]RoleBinding and ClusterRoleBinding
RoloBinding 可以将角色中定义的权限授予用户或用户组，RoleBinding 包含一组权限列表(subjects)，权限列表中包含有不同形式的待授予权限资源类型(users, groups, or service accounts)；RoloBinding 同样包含对被 Bind 的 Role 引用；RoleBinding 适用于某个命名空间内授权，而 ClusterRoleBinding 适用于集群范围内的授权
将 default 命名空间的 pod-reader Role 授予 jane 用户，此后 jane 用户在 default 命名空间中将具有 pod-reader 的权限
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-pods
namespace: default
subjects: #权利的标识点，把权限赋予给谁
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioRoleBinding 同样可以引用 ClusterRole 来对当前 namespace 内用户、用户组或 ServiceAccount 进行授权，这种操作允许集群管理员在整个集群内定义一些通用的 ClusterRole，然后在不同的 namespace 中使用 RoleBinding 来引用
例如，以下 RoleBinding 引用了一个 ClusterRole，这个 ClusterRole 具有整个集群内对 secrets 的访问权限；但是其授权用户 dave 只能访问 dev 空间中的 secrets(因为 RoleBinding 定义在 development 命名空间)
# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-secrets
namespace: dev # This only grants permissions within the "development" namespace.
subjects:
- kind: User
name: dave
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io使用 ClusterRoleBinding 可以对整个集群中的所有命名空间资源权限进行授权；以下 ClusterRoleBinding 样例展示了授权 manager 组内所有用户在全部命名空间中对 secrets 进行访问
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.ioroleRef与subjects
roleRef
roleRef字段指定了要绑定的角色的引用。它包含以下子字段：
- kind: 指明要引用的资源的类型，可以是Role或ClusterRole。
- name: 指明要引用的角色的名称。
- apiGroup: 指明要引用的资源所属的API组，通常是rbac.authorization.k8s.io。
subjects
subjects字段定义了一系列主体，这些主体将被授权访问roleRef中引用的角色。它包含以下子字段：
- kind: 指明主体的类型，可以是User、Group或ServiceAccount。
- name: 指明主体的名称。
- apiGroup: 对于Group类型的主体，指定API组，对于User和ServiceAccount类型的主体，通常默认为rbac.authorization.k8s.io。
- namespace: 指定ServiceAccount或Group主体所在的命名空间，如果主体是User类型，则该字段为空。
通过这些字段的组合，RoleBinding或ClusterRoleBinding资源将特定的角色与其授权的主体关联起来，从而实现了RBAC的授权机制.
roleRef和subjects字段的区别
-
roleRef字段：这个字段用于指定一个Role或ClusterRole对象，它告诉系统哪些权限规则应该被应用。在RoleBinding或ClusterRoleBinding资源中，roleRef引用了一个已经定义好的角色，以便将该角色的权限赋予特定的主体。
-
subjects字段：这个字段定义了哪些主体（用户、组或服务账户）将获得roleRef中指定的角色的权限。它包含了一系列的Subject对象，每个对象都指定了一个实体及其在集群中的位置（例如命名空间）。
使用流程
# statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
spec:
.........
serviceAccountName: rabbitmq-ha
..........
---
# SA.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
app: rabbitmq-ha
release: rabbitmq-ha
name: rabbitmq-ha
namespace: dev
secrets:
- name: rabbitmq-ha-token-hhrgd
---
# RoleBinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
app: rabbitmq-ha
release: rabbitmq-ha
name: rabbitmq-ha
namespace: dev
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: rabbitmq-ha
subjects:
- kind: ServiceAccount
name: rabbitmq-ha
---
# Role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app: rabbitmq-ha
release: rabbitmq-ha
name: rabbitmq-ha
namespace: dev
rules:
- apiGroups:
- ""
resources:
- endpoints
verbs:
- get
Resources
Kubernetes 集群内一些资源一般以其名称字符串来表示，这些字符串一般会在 API 的 URL 地址中出现；同时某些资源也会包含子资源，例如 logs 资源就属于 pods 的子资源，API 中 URL 样例如下
GET /api/v1/namespaces/{namespace}/pods/{name}/{}如果要在 RBAC 授权模型中控制这些子资源的访问权限，可以通过 / 分隔符来实现，以下是一个定义 pods 资资源 logs 访问权限的 Role 定义样例
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: default
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list"]to Subjects
权利的附着点：user，group，SA
RoleBinding 和 ClusterRoleBinding 可以将 Role 绑定到 Subjects；Subjects 可以是 groups、users 或者 service accounts
Subjects 中 Users 使用字符串表示，它可以是一个普通的名字字符串，如 “alice”；也可以是 email 格式的邮箱地址，如 “lztccc0831@163.com”；甚至是一组字符串形式的数字 ID 。但是 Users 的前缀 system: 是系统保留的，就这个不可以用.集群管理员应该确保普通用户不会使用这个前缀格式
Groups 书写格式与 Users 相同，都为一个字符串，并且没有特定的格式要求；同样 system: 前缀为系统保留
实践：创建一个用户只能管理 dev 空间
{
"CN": "devuser",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "BeiJing",
"L": "BeiJing",
"O": "k8s",
"OU": "System"
}
]
}
# 下载证书生成工具
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl
coreOS json
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /root/devuser-csr.json | cfssljson -bare devuser
# 设置集群参数
export KUBE_APISERVER="https://172.20.0.113:6443"
kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ssl/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=devuser.kubeconfig
# 设置客户端认证参数
kubectl config set-credentials devuser \
--client-certificate=/etc/kubernetes/ssl/devuser.pem \
--client-key=/etc/kubernetes/ssl/devuser-key.pem \
--embed-certs=true \
--kubeconfig=devuser.kubeconfig
# 设置上下文参数
kubectl config set-context kubernetes \
--cluster=kubernetes \
--user=devuser \
--namespace=dev \
--kubeconfig=devuser.kubeconfig
$ kubectl create ns dev
# 设置默认上下文
kubectl config use-context kubernetes --kubeconfig=devuser.kubeconfig
cp -f ./devuser.kubeconfig /root/.kube/config
kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev所以可以配合linux的用户，把config放在对应的用户的家目录下，这样登录对应的用户就只是管理对应的ns
Admission Controllers:准入控制
准入控制是API Server的插件集合，通过添加不同的插件，实现额外的准入控制规则。甚至于API Server的一些主要的功能都需要通过 Admission Controllers 实现，比如 ServiceAccount
官方文档上有一份针对不同版本的准入控制器推荐列表，其中最新的 1.14 的推荐列表是：
NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota列举几个插件的功能：
- NamespaceLifecycle： 防止在不存在的 namespace 上创建对象，防止删除系统预置 namespace，删除 namespace 时，连带删除它的所有资源对象。
- LimitRanger：确保请求的资源不会超过资源所在 Namespace 的 LimitRange 的限制。
- ServiceAccount： 实现了自动化添加 ServiceAccount。
- ResourceQuota：确保请求的资源不会超过资源的 ResourceQuota 限制。
扩展
Service Account与用户账户的区别
- Service Account（服务账户）和用户账户（User account）是Kubernetes集群中用于身份验证和授权的两种类型资源，它们在用途、作用范围和创建方式上有所不同。
用途和作用范围
-
Service Account：主要用于为Pod或其他资源提供身份验证和授权，以便它们能够与Kubernetes API进行交互。Service Account是Kubernetes中用于管理Pod身份验证和授权的重要资源，它使得Pod能够在集群中具有独立的身份，从而实现更精细的权限控制和安全策略。
-
User account：是为人设计的，用于集群外部的人员或服务，通常是通过证书、用户名和密码等凭据来进行身份验证。User account是跨namespace的，而Service Account则是仅局限它所在的namespace。
创建方式
-
Service Account：通常是由API Server创建，或者通过API调用手动创建。每个namespace都会自动创建一个default service account，而且可以根据需要创建更多的Service Account。
-
User account：在Kubernetes中不直接创建用户账户，而是通过kubeconfig文件管理用户的凭证信息。用户若要安全访问集群API Server，往往需要证书、Token或者用户名+密码。
权限控制
-
Service Account：需要通过RoleBinding或ClusterRoleBinding与Role或ClusterRole相绑定，以赋予相应的权限。
-
User account：通过RBAC创建ClusterRoleBinding或RoleBinding，将用户与角色绑定，以实现对Kubernetes集群中不同用户的访问控制。
default token与secret
-
Kubernetes中的Service Account默认Token与Secret有着密切的关系。当创建一个Service Account时，Kubernetes会自动为该Service Account创建一个默认的Secret，这个Secret包含了一个Token，该Token用于让Pod以Service Account的身份安全地访问Kubernetes API Server.
-
这个默认的Secret类型为kubernetes.io/service-account-token，它包含了三个关键部分：
- ca.crt（API Server的CA公钥证书）
- namespace（Service Account所属的命名空间）
- token（用于身份验证的Token).
-
当Pod启动时，如果没有指定特定的Service Account，它会默认使用其所属命名空间的default Service Account，并且会自动挂载这个Service Account对应的Secret到Pod的/var/run/secrets/kubernetes.io/serviceaccount/目录中.
-
这个Token是由API Server的私钥签名的，Pod中的容器可以使用这个Token来进行身份验证，以访问API Server.
-
总之，Service Account的默认Token是Kubernetes中用于身份验证的关键机制之一，它与Secret紧密相连，确保了Pod能够安全地访问集群资源.
Secret
- kubernetes.io/service-account-token是Kubernetes中的一种特殊类型的Secret，它与Service Account紧密相关，用于存储和管理Service Account的身份凭证。当创建一个Service Account时，Kubernetes会自动为该Service Account创建一个默认的Secret，这个Secret包含了一个Token，该Token用于让Pod以Service Account的身份安全地访问Kubernetes API Server。
结构和用途
kubernetes.io/service-account-token类型的Secret通常包含以下几个关键部分：
-
ca.crt：API Server的CA公钥证书，用于Pod中的进程对API Server的服务端数字证书进行校验。
-
namespace：Secret所在的命名空间的值的base64编码。
-
token：一段用API Server私钥签发的Bearer Token，在API Server的身份验证环节派上用场。
安全性和管理
- kubernetes.io/service-account-token类型的Secret应该受到严格的安全管理，以防止未经授权的访问。在生产环境中，建议定期更换Token，并监控对Secret的访问，以确保集群的安全。此外，可以通过调整Secret的注解来控制Token的有效期，例如设置token-max-age注解来限制Token的最大生存时间。
kubernetes.io/service-account-token类型的Secret应该受到严格的安全管理，以防止未经授权的访问。在生产环境中，建议定期更换Token，并监控对Secret的访问，以确保集群的安全。此外，可以通过调整Secret的注解来控制Token的有效期，例如设置token-max-age注解来限制Token的最大生存时间。
注意事项
-
不要在Service Account的secrets字段中引用手动创建的Secret，否则如果这些手动创建的Secret长时间未被使用将会被清理掉。
-
如果需要一个长期有效的Token，可以考虑使用TokenRequestAPI来获取，并通过投射卷（Projected Volume）挂载到Pod中，这样获得的Token具有固定的生命周期，并且当挂载的Pod被删除时这些Token将自动失效。
Kubernetes Service Account Token与API Server之间的交互机制
Kubernetes Service Account Token与API Server之间的交互机制主要涉及以下几个步骤：
-
1.Token的生成和存储：当创建一个Service Account时，Kubernetes会自动为该Service Account生成一个默认的Token，并将这个Token存储在一个Secret中。这个Secret包含了Token、CA证书和命名空间信息，并被挂载到Pod的/var/run/secrets/kubernetes.io/serviceaccount/目录中.
-
2.Token的使用：当Pod需要访问API Server时，它会使用Service Account Token来进行身份验证。Pod中的容器会从/var/run/secrets/kubernetes.io/serviceaccount/token文件中读取Token，并将其附加到HTTP请求的Authorization头部.
-
3.Token的验证：API Server收到带有Token的请求后，会使用自己的私钥对Token进行验证。验证过程包括检查Token的签名是否正确，以及Token是否尚未过期。同时，API Server还会使用Pod中的CA证书来验证自己的证书，确保通信的安全性.
-
4.权限检查：如果Token验证通过，API Server会进一步检查Pod的权限，确保它有权限访问请求的资源。这通常涉及到RBAC（基于角色的访问控制）规则的检查.
-
5.响应处理：如果一切验证都通过，API Server会处理Pod的请求，并返回相应的响应。如果验证失败，API Server会拒绝请求，并可能返回错误信息.
这个交互机制确保了只有持有有效Token的Pod才能安全地访问API Server，从而保护了Kubernetes集群的安全。
更新证书后的恢复
证书更新后，部分空间的部分服务，也就是单独挂载了SA的服务，会出现访问集群资源,pod,svc等资源权限的问题报错，报错内容如下
level=error ts=2024-06-26T08:08:37.127Z caller=klog.go:94 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:265: Failed to list *v1.Podnauthorized"
level=error ts=2024-06-26T08:08:37.129Z caller=klog.go:94 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:265: Failed to list *v1.Podnauthorized"
level=error ts=2024-06-26T08:08:37.129Z caller=klog.go:94 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:263: Failed to list *v1.Endnts: Unauthorized"
level=error ts=2024-06-26T08:08:37.131Z caller=klog.go:94 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:264: Failed to list *v1.Sere: Unauthorized"
level=error ts=2024-06-26T08:08:37.132Z caller=klog.go:94 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:264: Failed to list *v1.Sere: Unauthorized"
level=error ts=2024-06-26T08:08:37.133Z caller=klog.go:94 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:263: Failed to list *v1.Endnts: Unauthorized"
level=error ts=2024-06-26T08:08:37.134Z caller=klog.go:94 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:264: Failed to list *v1.Sere: Unauthorized"这是因为老的SA的token并没有更新,需要手动删除对应空间下的资源类型为:kubernetes.io/service-account-token 的secret,这时候k8s会自动生成新的token,可以-o ymal 确认,重新生成以后,SA的secretname也会改变成新的.之后需要重启相关引用此SA的服务,报错消失,服务正常
secret-token重新生成的原因
-
在Kubernetes中，Service Account (SA) 的 Token Secret 是用来为 Service Account 提供身份验证的凭证。当删除一个 Service Account 的 Token Secret 时，Kubernetes 会自动为该 Service Account 重新生成一个新的 Token Secret。这是因为 Service Account 的 Token Secret 对于集群的安全至关重要，它允许 Service Account 以特定的权限来访问集群资源。
-
当删除 monitor 空间的 Secret 后，Kubernetes 会检测到这个变化，并自动为 monitor 空间的 Service Account 创建一个新的 Token Secret。这是为了确保 Service Account 仍然能够正常工作，不会因为缺少凭证而无法访问集群资源。
-
至于 sa 中对应的 secrets 字段变为新的 Secret，这是因为 Kubernetes 的控制器（如 Prometheus Operator）会监听 Secret 的变化，并相应地更新其配置。当 monitor 空间的 Secret 被重新创建后，Prometheus Operator 会检测到这个变化，并更新其配置以使用新的 Secret。
-
这种行为是 Kubernetes 设计的一部分，旨在确保集群的安全性和稳定性。如果不希望 Kubernetes 自动重新创建 Secret，您可以考虑手动管理 Service Account 的 Token Secret，或者调整相关的控制器配置以禁用自动更新功能。但是，这通常不推荐，因为它可能会增加安全风险和维护复杂性。
