如何不挂载Service Accounts的token到Pod中？

目录一.系统环境二.前言三.Service Accounts(sa)简介四.在pod里设置sa的token不挂载到pod五.在sa里设置sa对应的token不挂载到pod上六.总结 一.系统环境 本文主要基于Kubernetes1.22.2和Linux操作系统Ubuntu 18.04。 服务器版本 docker软件版本 Kubernetes(k8s)集群版本 CPU架构 Ubuntu 18.04.5 LTS Docker version 20.10.14 v1.22.2 x86_64 Kubernetes集群架构：k8scludes1作为master节点，k8scludes2，k8scludes3作为worker节点。 服务器 操作系统版本 CPU架构 进程 功能描述 k8scludes1/192.168.110.128 Ubuntu 18.04.5 LTS x86_64 docker，kube-apiserver，etcd，kube-scheduler，kube-controller-manager，kubelet，kube-proxy，coredns，calico k8s master节点 k8scludes2/192.168.110.129 Ubuntu 18.04.5 LTS x86_64 docker，kubelet，kube-proxy，calico k8s worker节点 k8scludes3/192.168.110.130 Ubuntu 18.04.5 LTS x86_64 docker，kubelet，kube-proxy，calico k8s worker节点 二.前言 在我们使用Kubernetes进行容器化部署时，经常需要为Pod设置特定的权限。这种权限管理通常通过Kubernetes的服务账号（Service Accounts）实现。然而，默认情况下，Service Account的token会自动挂载到对应的Pod中，这可能引发一些安全问题。因此，本文将介绍如何设置Service Account的token不自动挂载到Pod中。 设置Kubernetes(k8s)服务账号Service Accounts(sa)的token不挂载到pod的前提是已经有一套可以正常运行的Kubernetes集群，关于Kubernetes(k8s)集群的安装部署，可以查看博客《Ubuntu 安装部署Kubernetes(k8s)集群》https://www.cnblogs.com/renshengdezheli/p/17632858.html。 三.Service Accounts(sa)简介 Service Accounts（服务账户）通常用于计算机程序或操作系统中。它们不是普通用户账户，而是被某些应用程序或服务用于特定的、通常自动化的任务。 在Kubernetes（一个开源的容器编排平台）中，Service Accounts主要为Pod中运行的进程提供身份。与面向人类的普通用户不同，Service Accounts由Kubernetes集群内的Pods/服务使用。 关于Service Accounts的关键点： 它们是有命名空间的：可以为每个命名空间创建Service Accounts，并且不能跨命名空间访问（除非被赋予明确的权限）。 默认情况下，当创建一个Pod时，Kubernetes会自动为其分配一个"default" Service Account，但你也可以创建并指定特定的Service Account。 Service Account 被绑定到一组角色（Roles），这些角色定义了 Service Account 的权限，例如对某些资源的读写权限等。 总的来说，Service Accounts 是一种安全和权限管理的机制，让我们能更好地控制在复杂环境中的应用程序和服务的访问权限。 默认情况下，Service Account的token会自动挂载到Pod内的应用程序使用。但在某些情况下，我们可能不希望token自动挂载，以避免潜在的安全风险。Service Accounts(sa)的token自动挂载到pod的方式具有安全隐患，假如我们拉取的镜像存有恶意代码，如果给了sa一个不正当的权限，pod使用这个sa权限的时候就可能干坏事，避免的方法有: 授予的权限最小化，够用就行 ; 如果没有必要 的话，不需要把sa的token挂载到pod里，不然恶意程序使用token干坏事。 关于Service Accounts(sa)的更多内容，请查看博客《Kubernetes(k8s)服务账号Service Accounts》。