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/