ServiceAccount为Pod钟的进程提供身份信息。当用户访问集群时（例如使用kubectl命令的时候），apiserver会将用户认证为一个特定的User Account（目前通常是admin，除非系统管理员自定义了集群配置）。Pod容器中的进程也可以与apiserver联系，当他们在连接apiserver的时候，他们会被认证为一个特定的service account（例如default）。

User account是为人设计的，service account是为Pod中的进程调用Kubernetes API而设计的。

  • User account是跨namespace的，而service account则是仅局限于它所在的namespace。

  • 每个namespace都会自动创建一个default service account

  • Token controller检测service account的创建，并为他们创建secret

  • 开启ServiceAccount Admission Controller后

    • 每个Pod在创建后都会自动设置spec.serviceAccount为default（除非指定了其他ServiceAccount）

    • 验证Pod引用的service account已经存在，否则拒绝创建

    • 如果Pod没有指定ImagePullSecretes，则把service account的ImagePullSecretes加到Pod中

      什么是ImagePullSecretes？

      是k8s中用于拉去私有容器镜像的机制。当你在集群中部署使用私有容器镜像的Pod时，通常需要提供身份验证凭据以获取访问权限。

      ImagePullSecrets 是一个或多个凭据的集合，用于访问私有的 Docker 镜像仓库。这些凭据通常是通过 Kubernetes 中的 Secret 对象来存储，并在 Pod 配置中引用。Pod 使用这些凭据来获取镜像仓库中的镜像，以确保能够成功拉取私有镜像。

      以下是一个示例，展示了如何在 Pod 配置中使用 ImagePullSecrets：

      yamlCopy codeapiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: my-container
      image: private-registry.com/my-image:latest
  imagePullSecrets:
    - name: my-secret

      在上面的示例中，imagePullSecrets 部分指定了一个名为 my-secret 的 Secret，这个 Secret 包含了访问私有镜像仓库所需的凭据。这样，Pod 就可以使用这个凭据来拉取 private-registry.com/my-image:latest 镜像。

      要使用 ImagePullSecrets，你需要执行以下步骤：

      1. 创建一个 Secret 对象，其中包含访问私有镜像仓库的凭据（如用户名和密码）。
      2. 在 Pod 的配置中的 imagePullSecrets 部分引用这个 Secret。
      3. 当 Pod 启动时，Kubernetes 将使用 ImagePullSecrets 中的凭据来拉取所需的私有镜像。

      总之，ImagePullSecrets 是 Kubernetes 中用于访问私有容器镜像的机制，它允许在 Pod 配置中引用存储在 Secret 中的凭据，以确保能够拉取私有镜像。

    • 每个container启动后都会挂载该service account的token和ca.crt到/var/run/secrets/kubernetes.io/serviceaccount/

在 Kubernetes 中，每个 Service Account 都有一个关联的安全令牌（Token），用于对 Kubernetes API 进行身份验证，以及一个与集群通信的根证书（ca.crt）。这些元素有助于确保 Service Account 在与 Kubernetes API 交互时的安全性。

  1. Token（令牌）：每个 Service Account 都会被分配一个安全令牌，用于身份验证。这个令牌是一个长字符串，它允许 Service Account 访问 Kubernetes API 中特定于命名空间的资源。当 Service Account 的 Pod 尝试与 API 服务器通信时，它会使用这个令牌进行身份验证，以获取访问权限。令牌会自动挂载到 Pod 中的 /var/run/secrets/kubernetes.io/serviceaccount/token 文件中，供应用程序使用。
  2. ca.crt（根证书）：与每个 Service Account 关联的根证书用于验证与 Kubernetes API 服务器之间的通信的安全性。根证书是集群的 CA（Certificate Authority）颁发的，用于加密和验证通信。在与 Kubernetes API 服务器进行通信时，Pod 可以使用这个根证书来验证服务器证书的有效性，确保通信的机密性和完整性。

这两个元素结合在一起，确保了 Service Account 的安全性和通信的安全性。Pod 使用令牌来证明自己的身份，同时使用根证书来验证服务器的身份，以确保与 Kubernetes API 服务器的交互是安全的。

请注意，Service Account 的 Token 和根证书是自动生成的，并在创建 Service Account 时为其分配。这些元素对于运行在 Kubernetes 集群中的应用程序来说是透明的，但它们在底层提供了身份验证和通信安全性的支持。

使用默认的Service Account访问API Server

当创建 pod 的时候，如果没有指定一个 service account，系统会自动得在与该pod 相同的 namespace 下为其指派一个default service account。如果获取刚创建的 pod 的原始 json 或 yaml 信息（例如使用kubectl get pods podename -o yaml命令），将看到spec.serviceAccountName字段已经被设置为 default。

[root@k8s-master ~]# kubectl get pods
NAME                     READY     STATUS    RESTARTS   AGE
filebeat-ds-hxgdx        1/1       Running   1          34d
filebeat-ds-s466l        1/1       Running   2          34d
myapp-0                  1/1       Running   0          3h
myapp-1                  1/1       Running   0          3h
myapp-2                  1/1       Running   0          4h
myapp-3                  1/1       Running   0          4h
pod-vol-demo             2/2       Running   0          2d
redis-5b5d6fbbbd-q8ppz   1/1       Running   1          2d

[root@k8s-master ~]# kubectl get pods/myapp-0 -o yaml |grep "serviceAccountName"
  serviceAccountName: default

[root@k8s-master ~]# kubectl describe pods myapp-0
Name:               myapp-0
Namespace:          default
......
Volumes:
  ......
  default-token-j5pf5:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-j5pf5
    Optional:    false

从上面可以看到每个Pod无论定义与否都会有一个存储卷，这个存储卷为default-token-*** token令牌，这就是service account是为Pod中的进程与apiserver联系提供身份认证信息。通过secret进行定义，由于认证信息属于敏感信息，所以需要保存在secret资源当中，并以存储卷的方式挂载到Pod当中。从而让Pod内运行的应用通过对应的secret中的service account来连接apiserver，并完成认证。每个 namespace 中都有一个默认的叫做 default 的 service account资源。可以使用kubectl get secret命令当前名称空间内的secret，也可以看到对应的default-token。可以使用的预制认证信息让当前名称空间中所有的pod连接至apiserver，从而保证pod与apiserver之间的通信。

[root@k8s-master ~]# kubectl get sa
NAME      SECRETS   AGE
default    1         50d

[root@k8s-master ~]# kubectl get sa -n ingress-nginx  #前期创建的ingress-nginx名称空间也存在这样的serviceaccount
NAME                           SECRETS   AGE
default                        1         11d
nginx-ingress-serviceaccount   1         11d

[root@k8s-master ~]# kubectl get secret
NAME                    TYPE                                  DATA      AGE
default-token-j5pf5     kubernetes.io/service-account-token   3         50d
mysecret                Opaque                                2         1d
tomcat-ingress-secret   kubernetes.io/tls                     2         10d

[root@k8s-master ~]# kubectl get secret -n ingress-nginx
NAME                                       TYPE                                  DATA      AGE
default-token-zl49j                        kubernetes.io/service-account-token   3         11d
nginx-ingress-serviceaccount-token-mcsf4   kubernetes.io/service-account-token   3         11d

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

创建一个ServiceAccount

[root@master-1 app]# vim serviceaccount.yaml 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin
  namespace: default

[root@master-1 app]# kubectl apply -f serviceaccount.yaml 
serviceaccount/admin created

[root@master-1 app]# kubectl get sa
NAME              SECRETS   AGE
admin             1         31s
default           1         20d
nfs-provisioner   1         18d

[root@master-1 app]# kubectl get secret
NAME                          TYPE                                  DATA   AGE
admin-token-j7n8j             kubernetes.io/service-account-token   3      27m
default-token-zmv4x           kubernetes.io/service-account-token   3      20d
mysecret                      Opaque                                2      19d
nfs-provisioner-token-xjn7p   kubernetes.io/service-account-token   3      18d

[root@master-1 app]# kubectl get sa admin -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"admin","namespace":"default"}}
  creationTimestamp: "2019-02-12T03:07:07Z"
  name: admin
  namespace: default
  resourceVersion: "2606053"
  selfLink: /api/v1/namespaces/default/serviceaccounts/admin
  uid: 48250903-2e73-11e9-a8c7-d8490b8af3ae
secrets:
- name: admin-token-j7n8j

看到有一个 token 已经被自动创建，只需要在 pod 的spec.serviceAccountName 字段中将name设置为您想要用的 service account 名字即可。在 pod 创建之初 service account 就必须已经存在，否则创建将被拒绝。需要注意的是不能更新已创建的 pod 的 service account

ServiceAccount的自定义使用

这里在default名称空间创建了一个serviceaccount为admin，可以看到已经自动生成了一个Tokens：admin-token-j7n8j，下面展示如何使用自定义的serviceaccount

[root@master-1 app]# vim pod-sa-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-sa-demo
  namespace: default
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort: 80
  serviceAccountName: admin

[root@master-1 app]# kubectl apply -f pod-sa-demo.yaml 
pod/pod-sa-demo created

[root@master-1 app]# kubectl describe pods pod-sa-demo
......
Volumes:
  admin-token-j7n8j:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  admin-token-j7n8j
    Optional:    false
......

User Account的定义以及使用

在K8S集群当中，每一个用户对资源的访问都是需要通过apiserver进行通信认证才能进行访问的，那么在此机制当中，对资源的访问可以是token，也可以是通过配置文件的方式进行保存和使用认证信息，kubectl命令行工具使用kubeconfig文件来查找选择群集并与群集的APIserver进行通信。可以通过kubectl config进行查看编辑kubeconfig配置文件，配置文件路径$HOME/.kube/config文件，eg：/root/.kube/config 如下：

[root@k8s-master mainfests]# kubectl config view
apiVersion: v1
clusters:  #集群列表
- cluster:
    certificate-authority-data: REDACTED
    server: https://192.168.56.11:6443
  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的标准资源之一，在该配置文件当中定义了一个集群列表，指定的集群可以有多个；用户列表也可以有多个，指明集群中的用户；而在上下文列表当中，是进行定义可以使用哪个用户对哪个集群进行访问，以及当前使用的上下文是什么。如图：定义了用户kubernetes-admin可以对kubernetes该集群的访问，用户kubernetes-user1对Cluster1集群的访问。

在这里插入图片描述

自建证书和账号进行访问apiserver演示

注意：此步骤在/etc/kubernetes/pki路径下执行，因为需要用到Kubernetes CA证书。

  1. 生成证书

    [root@k8s-master pki]# (umask 077;openssl genrsa -out magedu.key 2048)
Generating RSA private key, 2048 bit long modulus
............................................................................................+++
...................................................................................+++
e is 65537 (0x10001)

    [root@k8s-master pki]# ll magedu.key 
-rw------- 1 root root 1675 Oct 12 23:52 magedu.key

  2. 使用ca.crt进行签署

    [root@k8s-master pki]# openssl req -new -key magedu.key -out magedu.csr -subj "/CN=magedu"  证书签署请求(CN表示用户名，O表示组)

    [root@k8s-master pki]# openssl x509 -req -in magedu.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out magedu.crt -days 365  #证书签署
Signature ok
subject=/CN=magedu
Getting CA Private Key

    [root@k8s-master pki]# openssl x509 -in magedu.crt -text -noout

    生成证书和签署证书是证书颁发的两个不同步骤，这两个步骤涉及到不同的操作和角色，用于创建和验证数字证书的完整新和合法性。

    • 生成证书：在这个步骤中，证书的申请者（通常是实体，服务器胡总和客户端）生成一个密钥对，包括一个私钥和一个公钥。 私钥用于加密和解密数据，而公钥用于加密和验证签名。然后证书申请者会将公约和一些标识信息（如域名，组织名称等）提供给证书颁发机构（CA）
    • 签署证书：在这个步骤中，证书颁发机构（CA）使用其自己的私钥来对证书申请者提供的公钥和标识信息进行签名。这个签名包括一些元数据，比如颁发者，有效期，颁发日期等。

  3. 添加到用户认证

    [root@k8s-master pki]# kubectl config set-credentials magedu --client-certificate=./magedu.crt --client-key=./magedu.key --embed-certs=true
User "magedu" set.

    [root@k8s-master pki]# kubectl config set-context magedu@kubernetes --cluster=kubernetes --user=magedu
Context "magedu@kubernetes" created.

    [root@k8s-master pki]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://192.168.56.11:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
- context:
    cluster: kubernetes
    user: magedu
  name: magedu@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
- name: magedu
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

    [root@k8s-master pki]# kubectl config use-context magedu@kubernetes
Switched to context "magedu@kubernetes".

    [root@k8s-master pki]# kubectl get pods
No resources found.
Error from server (Forbidden): pods is forbidden: User "magedu" cannot list pods in the namespace "default"
# kubernetes
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes