ServiceAccount — 工作负载的身份

一句话总结

人们通过外部认证系统证明身份，但Pad通过ServiceAccount证明身份。那个证明书是代币，最近代币会过期。

为什么需要这个？

在群集中运行的程序也会调用API。操作员、控制器、监控代理、CI Runner都是如此。无法向他们发放人账号，所以Kubernetes设置了工作负载专用身份信息ServiceAccount。Pad将自己的SA的令牌作为文件挂载，apiserver用该令牌来辨别主体。接下来，判断由前面的模块学习到的RBAC进行。认证（是谁）和授权（可以做什么）是分开的的结构在这里清晰可见。

问题是以前的方式。在1.24之前，创建SA时，会自动生成一个包含代币的Secret，那个代币没有到期。一旦泄露，意味着永久有效的身份证件会在每个群集中滚动数十个。没有办法追踪被记录在日志上的还是留在图像图层上的副本。

怎么行动

从1.24开始，基本变更了。即使创建SA，Secret也不会自动生成，在PAD上安装了有固定寿命的projected代币。kubelet在到期前会自动更新，所以应用程序只需要重新读取文件即可。

用手收到代币时使用TokenRequest API。

kubectl create token payments -n sa-lab --duration=3600s --audience=vault

打开这个代币的付款包，可以看到三个。sub是主体（system:serviceaccount:<네임스페이스>:<이름>),aud是将这个代币用在哪里，exp哇iat是寿命。aud之所以如此重要，是因为防止重复使用攻击。如果发给Vault的令牌也能通过apiserver，那么一个地方被破解后，其他地方也会被打开。被卡住的目标的令牌只在那个目标上有效。

直接在护肤霜说明上写的话会变成这样。

volumes:
  - name: vault-token
    projected:
      sources:
        - serviceAccountToken:
            audience: vault
            expirationSeconds: 3600
            path: vault-token

这种结构是云工作负载身份的基础。将帕德收到的这个短寿命的令牌提交给云STS，将其转换为临时证书。要保存的静态密钥完全消失。

也有相反方向的控制。对于不需要代币的帕德，根本不给。

spec:
  automountServiceAccountToken: false

这个字段可以应用于Pad和ServiceAccount。如果挂在账户上，就会对使用该账户的所有Pad进行基本应用。像Web服务器一样完全不调用API的工作没有理由持有令牌，当容器被破解时，攻击者要拿走的东西减少了一件。

仍然可以制作传统方式。kubernetes.io/service-account-token在类型Secret上kubernetes.io/service-account.name添加注释后会生成无到期的代币。虽然这是在群集之外的工具不支持TokenRequest时的最后手段，但没有到期意味着由人100%负责废弃程序，因此不推荐。

在现场相遇的样子

**第一，滥用default服务账户。**未指定SA的派对是命名空间的default使用。结果，一个命名空间的所有帕德共享相同的身份，只要稍微给予一点权限，该权限就会传播给所有人。每个帕德都提供专用SA是基本。

**第二，权限仍然由RBAC决定。**即使创建了SA，也不会产生任何权限。相反，一个方便地放置的绑定可能会给工作负载过多的权限。--as问的习惯在这里也有效。

**第三，令牌文件路径。**基本挂载路径是/var/run/secrets/kubernetes.io/serviceaccount也是在集装箱除臭事故分析中攻击者首先确认的途径。要记住，侧卡或调试集装箱也会看到同样的东西。

下次实习要做的事情

制作专用SA，粘贴在平板电脑上，确认自动安装的代币体积。在平板电脑和账户两边尝试应用关闭代币的两种方法，解码TokenRequest收到的代币的载荷，直接读取主体、对象、寿命。在明细中写上指定对象的projected代币，制作Legacy长期代币Secret，整理风险后，最后制作使用现状审计报告。