从外部管理集群的最佳实践答案

【问题标题】：Best practice for managing the cluster from the outside从外部管理集群的最佳实践
【发布时间】：2020-03-24 06:17:18
【问题描述】：

我有一个最佳实践问题：

我有一个 Django 应用程序在跟踪我的最终用户帐户的某个地方（非 k8s）运行。另外，我有一个为每个用户提供服务的 k8s 集群。当一个新用户在 Django 中注册时，应该在集群中创建一个新服务。

这样做的最佳做法是什么？我看到的两个选项是：

在集群中有一个长期存在的服务，比如user-pod-creator，它向 Django 端公开一个 API，允许它请求创建一个 pod。
授予Django直接使用集群API的权限；让它按照自己的意愿创建（和删除）pod。

直觉上我更喜欢第一个，因为它产生的关注点分离以及出于安全原因。但是第二个会给 Django 应用程序提供很大的灵活性，这样它不仅可以创建和删除 pod，而且如果需要直接 API 调用，它可以对集群有更多的可见性，而不是我必须公开新的 API 端点在user-pod-creator 或其他一些服务中。

【问题讨论】：

我的意思是选项 1 只是解决了问题。最后需要与 Kubernetes API 对话。如果您想应用自己的授权规则或日志记录，构建外观服务可能很有用，并且它将被多个内部事物使用。或者，如果您想分离事物，以便更广泛地测试特权组件。但除此之外，在一个新的地方也是同样的问题。

标签： kubernetes

【解决方案1】：

选项 2 是一种有效的方法，可以通过 service account 解决。

为您的 Django 应用创建一个ServiceAccount：

kubectl create serviceaccount django

这个ServiceAccount指向一个Secret，这个Secret包含一个token。

找出与 ServiceAccount 关联的 Secret：

kubectl get serviceaccount django -o yaml

获取 Secret 中的令牌：

kubectl get secret django-token-d2tz4 -o jsonpath='{.data.token}'

现在您可以在集群外的 Django 应用发出的 Kubernetes API 请求中将此令牌用作 HTTP 不记名令牌。

也就是说，在 Kubernetes API 请求的 HTTP Authorization 标头中包含令牌，如下所示：

Authorization: Bearer <TOKEN>

这样，您的请求就会通过 API 服务器中的身份验证阶段。但是，服务帐户还没有权限（授权）。

您可以使用 Roles 和 RoleBindings 为您的服务帐户分配所需的权限：

kubectl create role django --verb <...> --resource <...>
kubectl create rolebinding django --role django --serviceaccount django

关于安全性：仅授予服务帐户所需的最低权限（最小权限原则），如果您认为有人窃取了服务帐户令牌，您可以使用kubectl delete serviceaccount django 删除服务帐户以使令牌失效。

另请参阅here 以获取所介绍方法的示例。特别是：

服务帐户不记名令牌完全可以在集群外使用，并可用于为希望与 Kubernetes API 对话的长期作业创建身份。

【讨论】：