Kubernetes！似乎全世界都对这个新的软件部署平台感到兴奋。
Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化工作负载和服务，它促进了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。
哪些工作负载正迁移到 Kubernetes？
迁移到 Kubernetes 的工作负载有三种类型。
在第一种情况下，认证基础设施可能不会改变。虽然你可以使用认证服务向你的应用添加单点登录，但更改不会是针对 Kubernetes。此外，为了最大限度地降低风险，你需要在考虑更改应用代码之前完成迁移。
但是，在后两种情况下，你需要确保用户和微服务的访问都得到适当的控制。在这些情况下，你需要考虑如何在基于 Kubernetes 的微服务架构的背景下实施认证和授权。
什么是Auth？
Auth 是认证和授权的组合，描述了谁在发出请求以及允许他们执行什么操作。通常情况下，Auth 还包括用户管理，即配置用户，然后可以对其进行认证和授权。
如上所述，Kubernetes 内置了大量复杂的功能，例如扩展和弹性。这是使用它的主要原因！
但 Auth 不是内置服务。你需要自己选择或构建服务来提供这个功能。在 Kubernetes 中，需要考虑多个级别的Auth。
基础设施认证
第一种认证控制对 Kubernetes 管理资源的访问。例如，控制谁可以启动 pod 或创建部署。
此功能定义明确，你可以使用各种不同的机制来实施访问控制。控制谁可以查看、删除和修改基础设施是相当重要的。
如果你使用 OpenID Connect (OIDC) 将此功能委托给一个独立的认证服务，那么要小心它在控制访问的 Kubernetes 集群中运行。（这是关于如何使用 OIDC 和 FusionAuth 设置此类 RBAC 的教程。）你不希望该服务不可用，然后无法管理你的集群。
避免这种命运的选择包括：
应用认证
另一种类型的认证处于不同的抽象级别：应用层。也就是说，你的应用如何知道请求来自谁，以及用户或实体有权做什么？几乎所有应用都有用户和权限的概念，这些权限控制着他们可以访问的内容。
让我们考虑上面提到的两个情况：将应用向微服务发展或将已经拆分为微服务的应用移植。新建的微服务应用具有与后者相同的认证注意事项。
如果你正在向微服务发展单体应用，则需要将应用拆分为有界上下文。用户管理和Auth是常见的上下文，并且大多数开发人员对域对象的定义都很了解。因此，Auth可能是一个不错的选择。
采取的步骤是：
选择一个Auth服务器并将其部署到 Kubernetes。
规划你的应用需要的组和角色。
将你的应用设置委托给认证服务器。通常你可以使用开源库来处理认证过程。
修改你的应用以确保它可以使用认证过程的结果，使用角色或权限正确控制访问。你可能需要调整处理会话的方式。
评估你的用户数据，并决定你是否要对这些数据进行快速或缓慢的迁移。
执行执行一个测试迁移到一个临时的认证服务器实例。你还可以指向应用的临时环境以测试应用集成是否正确。
迁移你的用户数据，并用新的代码更新你的应用生产环境，将认证委托给认证服务器。
致力于将其他上下文作为微服务迁移到 Kubernetes。
在构建新的微服务应用时，关注点略有不同。
虽然你仍希望将认证服务器部署到 Kubernetes 来管理用户，但你也希望认证系统能作为安全令牌服务（STS）。使用STS可以让你建立一个零信任的、基于令牌的策略。下面我将详细介绍。
网关上的认证
微服务通常以 API 网关或入口为前端。这可以在 Kubernetes 集群前完成，也可以通过在其中运行的 NGINX pod 完成。
该网关还需要对请求进行认证和授权。
有几个选择，它可以使用令牌；有时限的凭据通常由 Auth 授权生成。令牌灵活且安全，可以由独立的认证服务器生成。API 网关通常支持验证令牌，特别是如果它是 JSON Web 令牌 (JWT)，这是一种常见格式。
下面，API 网关在允许该网关后面的服务进行访问之前，检查客户端令牌。
客户端持有的 API 密钥是一种替代方法，在概念上更简单。一些 API 网关内置了对 API 密钥的限制、管理和轮换的支持。
微服务之间的认证
在微服务系统中，有多种方法可以对请求进行认证和授权：
MTLS 或客户端证书：其中服务具有客户端证书并将其作为每个请求的一部分呈现。适用于服务与服务之间的通信，但客户端证书通常不绑定到个人用户。
API 密钥：与客户端证书类似，这些是每个服务拥有的用于唯一标识它们的任意字符串。如果你使用这些，请确保你计划轮换。由于这些字符串不是可加密验证的，因此它们不如客户端证书安全，但它们更容易实现。
代币：这些短期凭证可以包含有关承载者的信息。通常，JWT 被用作这些令牌。它们通常经过加密签名，因此其内容可以被信任。
STS 可用于创建与一个服务唯一绑定的令牌。下面，提醒服务正在执行客户端凭据授予，以获取Todo服务的令牌。
虽然你可以选择多个解决方案来实施，但令牌是最灵活的。如上所述，它们可以授予集群外部的客户端，并在 API 网关上进行检查。令牌可能包含授权信息，例如角色或权限。它们还可以包含任何其他有用的数据，可以用JSON表示。STS 也可以为每个用户请求甚至每个微服务请求生成令牌。
认证注意事项
当你考虑 Kubernetes 管理的微服务中的应用认证时，请考虑以下场景：
用户驱动的微服务认证请求：集群中的应用已收到用户请求。你需要确定用户是谁以及他们可以执行哪些操作。
服务与服务之间请求：当计划的作业运行时，它们可能需要多个微服务。你想知道微服务 A 被授权访问微服务 B。
从一个微服务向另一个微服务发出的请求：这是前两种情况的混，一个请求进来，一个微服务处理它，但需要代表用户访问其他服务。这种混合是有用的，但也是可选的。
在处理这些类型的请求时，你可以选择令牌处理：
将用户提供的令牌传递给每个微服务。API 网关不进行任何处理。
在 API 网关上或在请求通过它之后立即创建一个新令牌。该新令牌可以具有用户提供的信息子集、不同的到期时间，并由不同的密钥签名。
将客户端提供的令牌转换为表单参数或标头，以便从微服务中删除所有令牌处理。
要求微服务之间的每个请求都通过有效的、特定的微服务的令牌进行认证，可能包括来自上游提供的令牌的特定用户的详细信息。
其中哪一个有意义，取决于 API 网关处理的令牌中提供了哪些信息、每个微服务需要多少信息、访问令牌被泄露的风险以及你是否要分布授权逻辑。
最后，你可以构建一个服务来自己铸造这些令牌，但是有一组强大的 Kubernetes 友好的Auth提供者。这些服务可以处理认证和将授权信息嵌入到令牌中。因此，更好的选择是在你拥有的场景中，找到一个在 Kubernetes 中运行良好的认证程序。有很多可供选择的，包括商业和开源。
选择认证程序
这种认证程序的标准是什么？具体细节取决于你要迁移或运行的应用类型，但有一些共同的属性。
可作为容器进行部署。如果你在 Kubernetes 中运行，则认证提供的应用部分应该是容器化的。你通常不希望你的认证程序位于集群外部，特别是如果你用它来铸造令牌，以便在你的微服务系统中使用。
快速。根据你的场景，每次从一个微服务向另一个微服务发出请求时，你都可能从该认证提供程序获取令牌，因此要选择一个高性能的。即使你从一个单体应用中提取认证，你仍然希望它是快速的，因为用户想要获得你正在构建的功能，而不是花时间登录。
可扩展性。你要确保你使用的任何认证服务器都可以横向扩展，因为认证的关键瓶颈在于 CPU 密集型密码散列操作。
符合标准。确保你的认证程序支持 OAuth2、OIDC 和相关的令牌 RFC，例如RFC 7519。
API 优先，支持用于管理集群的工具。你需要像管理集群一样管理此认证服务器的配置，无论是使用 Terraform、Pulumi 还是 Golang 代码。
支持 mTLS。这是一个不错的选择，你可以使用NGINX sidecar添加它，但如果你使用客户端证书，则需要确保认证服务器也支持它们。
Kubernetes中的Auth对于开发者和DevOps的作用
一旦建立了认证服务器并，开发人员就不必担心用户安全和认证或授权。开发人员可以将认证卸载到外部服务，而不是编写登录页面并确保正确生成令牌。他们能够专注于编写业务逻辑。
对于 DevOps人员和运营商，认证服务器提供了一种标准方式来实现认证、授权和用户管理。不过，他们需要决定是否在基础设施级别使用认证服务器。
开发人员和 DevOps 从业者都应该在正确类型的凭证上进行协作，以便在 Kubernetes 中运行的应用内部和边界上使用：令牌、API 密钥、客户端证书或三者的某种组合。
结论
Kubernetes 通过自动化软件生命周期的一部分，包括部署、回滚和扩展，可以更轻松地开发软件。然而，它并没有提供所有的通用基础设施。
认证和授权是需要 Kubernetes 友好的第三方解决方案和一些集成工作的组件。但是，通过将认证作为一项单独的服务并将令牌用作短期凭证，允许开发人员专注于编写业务逻辑。
本文为翻译文章，原文链接：
https://containerjournal.com/features/auth-in-the-age-of-kubernetes/
