我正在努力了解其目的是什么？
例如下面的pod定义：
dash_auth/basic_auth.py服务帐户何时“重要”？它涉及什么交互？
https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/解释了如何设置非默认值，但没有真正提及更改了什么效果/交互-或为什么需要这样做？
它真正给出的唯一提示是本节：
吊舱内部容器中的进程也可以联系apiserver。 当他们这样做时，它们被认证为特定的服务帐户 （例如，默认）。
这是什么意思。当任意进程向kubernetes API服务器发送HTTP请求时，它如何神奇地变成“已认证”？
有安全保障吗？如果是这样，他们是什么？
答案 0 :(得分：1)
需要与Kubernetes API Server交互的Pod需要一个服务帐户才能向Kubernetes API Server进行身份验证。
要与API服务器通信，Pod使用包含身份验证令牌的ServiceAccount。然后，可以将角色（例如：列出给定名称空间中所有Pod的权限）或ClusterRole（例如：读取整个集群中所有Secrets的权限）绑定到此ServiceAccount。分别使用RoleBinding或ClusterRoleBinding，因此ServiceAccount被授权执行这些操作。
许多在群集中运行的应用程序（请阅读：在Pods中运行）需要与API服务器进行通信。其中包括在控制平面内运行的进程（调度程序，控制器管理器，代理等），以及需要对集群执行某种形式的管理的所有应用程序，例如管理自定义资源的控制器。
答案 1 :(得分：0)
根据我的经验，当群集中的RBAC处于活动状态时（您应该！），并且Pod必须与Kubernetes API通信时，才需要ServiceAccount。
让我们假设您有一个使用Kubernetes客户端扩展kubernetes行为的Pod。例如，每次Kubernetes节点加入集群时，您都可以在Slack上发送消息。为了允许Pod中运行的程序与Kubernetes API进行交互，您必须通过证书。 ServiceAccount为您完成此任务。并且根据您使用的ServiceAccount可以限制权限。
几乎与AWS世界一样，EC2通过IAM角色和EC2配置文件对AWS API进行身份验证。
答案 2 :(得分：0)
api-server理解两种类型的请求：已认证和未认证。然后，可以对授权的请求进行授权或不授权。
Service Account，User或Group（一组用户）是包含与api-server进行交互的特定权限的对象。
您将使用User或Group授予一个人或一群人访问权限，并与api-server进行交互；主要通过kubectl。您也可以curl api-server端点，作为RESTful API，并带有证书。
但是，当您需要微服务（容器）与api-server进行交互时，您需要指定一个Service Account；并具有所有必要的权限。
所有权限都是通过RBAC规则赋予的。
结论：
您将创建一个User或Group并为其授予一定的权限，以便与api-server作为个人进行交互。
如果您希望广告连播作为服务器（而不是作为个人）与Service Account进行交互，则您将创建一个api-server，并为其授予某些权限。
答案 3 :(得分：0)
它与https://kubernetes.io/docs/concepts/policy/pod-security-policy/
有关文档中没有提及这一事实确实令人惊讶。