需要了解pod自动计算服务帐户机密的原因。
如果我们禁用服务帐户的automout，这会影响我们的应用程序的任何操作吗？该应用程序已经在pod规范部分中指定了服务帐户，但服务帐户的automout没有被禁用。
如何禁用服务帐户的自动装载在链接文档中进行了解释：
在版本1.6+中，您可以选择退出自动加载API凭据通过设置
automountServiceAccountToken: false来服务帐户服务帐户。在1.6+版本中，您还可以选择不自动安装API凭据对于特定的吊舱。
还有一些解决方案可以缓解安全问题：
-
使用RBAC
-
使用变异的webhooks
如果我们禁用自动退出服务帐户，这会影响我们的应用程序的任何操作吗？该应用程序已经在pod规范部分中指定了服务帐户
如果禁用SA机密的自动加载，Pod将无法访问K8s API服务器或执行任何其他需要作为服务帐户进行身份验证的操作。很难说这是否会影响你的工作量，只有你自己才能知道。只与其他用户定义服务对话的web服务器或工作Pod在没有SA访问的情况下可能会很好，但如果他们想从应用程序Pod中生成K8s作业，他们需要SA。
但我想了解为什么服务帐户的秘密会被装载到pod，尽管这是一种安全升级。
关键似乎是，在计算机安全领域，我们需要权衡方便性和安全性。将SA secretes自动安装到Pod中使使用K8s API变得容易(=>更方便(。默认情况下禁用它更安全，但也不太方便，因为您需要明确标记那些需要访问K8s API的Pod。这是否是一个太大的负担在很大程度上取决于工作量，而且可能没有适合每个人的默认答案。
为什么没有更改为更安全的默认值？
这里有答案：
默认情况下禁用是不向后兼容的，因此不是现实的选择，直到(如果(一个v2 Pod API成为
和此处：
我并不是说这是不合理的，只是说这将是一个Kubernetes的GA分发难以下咽。我能看到这发生在v2 pod API中。
如果您使用工作负载标识从pod访问azure服务，那么我认为您需要服务帐户令牌。这是因为您的pod的azure CLI或SDK会将k8s服务帐户令牌交换为azure服务令牌。
某些运行时(如dotnet(的Application Insights库使用服务帐户令牌通过k8s API收集有关部署环境的信息。Java的则不然。