我对kubernetes相当陌生，我正在尝试创建普通用户，这些用户对其特定名称空间的访问将受到限制。
我遵循了文档“证书签名请求/普通用户”，并且已经成功创建了一个测试用户，并且能够限制该用户的特权。我试图了解我是否可以为该用户提供对仪表板的访问权限，并且只能查看其自己的资源，例如仅查看其名称空间。
在我的过程中，我发现所有文档都提到您需要具有服务帐户才能访问“创建仪表板”示例用户。
然后，我继续阅读该服务帐户“管理服务帐户”。“用户帐户用于人类。服务帐户用于在pod中运行的流程。”
在社区中的一个相关问题中，是否可以为Kubernetes中的普通用户创建令牌？。同样，这个问题的答案是创建一个服务帐户，但是正如官方文档中记录的那样，我们应该将服务帐户用于在Pod上运行的流程。
我对此主题有些困惑，如果用户（非管理员）应该能够访问Dashboard并查看与绑定他的角色相同的资源，那么有人可以分享最佳实践，或者可能还需要更多信息吗？
创建bearer token和连接的最常见方法Kubernetes Dashboard是使用ServiceAccount。
但是，如果要创建Bearer Token，则User Account必须根据我的知识使用静态令牌文件。
在方案中，要允许user account访问的地方，Kubernetes Dashboard必须考虑使用Authorization标头选项。
通过HTTP访问授权标头是使Dashboard充当用户的唯一方法。请注意，由于纯HTTP流量容易受到MITM攻击，因此存在一些风险。
要使Dashboard使用授权标头，您只需要在向Dashboard的每个请求中传递Authorization：Bearer。这可以通过在仪表板前面配置反向代理来实现。代理将负责与身份提供者进行身份验证，并将在请求标头中生成的令牌传递给仪表板。请注意，需要正确配置Kubernetes API服务器以接受这些令牌。
出于测试目的，您可以使用允许您修改请求标头的插件。
边注
Authorization header will not work if Dashboard is accessed through API server proxy。指南中描述的访问仪表板的方式kubectl proxy和API Server方法均Accessing Dashboard无效。这是因为，一旦请求到达API服务器，所有其他标头都会被丢弃。
的示例reverse proxy是Kublr。您可以在Kubernetes博客中的利用客户端证书和承载令牌进行身份验证中找到更好的描述。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句