Istio：快速入门

第 6 章. 安全与身份

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

长期以来，应用程序和系统的安全都集中在网络上。 从历史上看，我们建立了坚固的外壳（防火墙、VPN 等）来抵御攻击，但一旦外壳被攻破，攻击者就可以轻易访问许多系统。 但是，我们在自己的信任域内构建了深度防御并应用了网络隔离概念，这就要求安全管理员在网络上打洞，并将一切设置成这样，这里分配这些网络身份（IP 地址），那里分配这些访问权限，这里通过这些端口输送，等等，这样我们的应用程序才能相互通信。当系统变化率较低时，这种安全方法就能很好地发挥作用，而当变化在几天内发生时，采取手动步骤或自动设置和维护网络就会变得更加容易。

但是，当涉及到基于容器的系统时，变化的速度就不是以天为单位了，而是以秒为单位。在高度动态的环境中，传统的网络安全模式就会崩溃。问题的关键在于，传统网络安全将重点放在网络唯一可用的身份上：IP 地址。 IP 地址并不能有力地表明应用程序，而且由于 Kubernetes 等动态环境可以随着时间的推移为不同的工作负载自由重复使用 IP 地址，因此不足以用于策略或安全。

为了解决这个问题，Istio 的主要功能之一是为服务网格中的每个工作负载颁发一个身份。 这些身份与工作负载绑定，而不是与某些特定主机（或某些特定网络身份）绑定。这意味着你可以编写服务与服务间通信的策略，这些策略对部署和系统拓扑的变化具有鲁棒性，而不是与网络有界。

在本章中，我们将探讨与服务间通信相关的身份、授权和验证概念。我们还将深入探讨 Istio 如何为工作负载提供身份，如何在运行时对这些身份进行验证，以及如何使用它们授权服务间通信。让我们从访问控制开始。

访问控制

访问控制系统要回答的基本问题是："实体能否 对对象执行操作？我们称这个实体为 "委托人"。操作是系统定义的一些操作。 对象是被委托人执行操作的事物。以 Unix 文件系统为例，用户委托人可以对文件对象执行 "读取"、"写入 "或 "执行 "操作。

身份验证

身份验证与委托人有关。 身份验证是获取某种凭证（如证书）、验证凭证是否有效（即凭证是否真实）并确保访问控制问题中的实体包含事实上代表该实体的身份的过程。授权是指实体可以和不可以对对象执行哪些操作。

认证（缩写为authn，发音为 "auth-in"）是从请求中获取凭证并确保其真实性的行为。在 Istio 中，服务相互通信时使用的凭证是X.509 证书。 服务代理通过使用正常的证书验证流程验证对方提供的 X.509 证书，从而验证调用服务的身份（客户端与服务器相互验证）。如果证书有效，证书中编码的身份即被视为已通过验证。一旦进行了身份验证，我们就说委托人通过了身份验证，称其为 "通过身份验证的委托人"，以区别于可能通过也可能未通过身份验证的委托人。

授权

授权（缩写为authz，发音为 "auth-zee"）是回答问题 "实体是否 被允许 对对象执行操作？"的行为 。例如，要在 Unix 上运行 shell 脚本，系统会检查当前用户（经过身份验证的委托人）是否拥有脚本文件的执行权限。在 Istio 中，服务与服务之间的通信授权是通过 RBAC 策略配置的，我们将在本章后面详细介绍 RBAC 策略。

注释

我们还使用缩写 "auth "来指 authn 和 authz。

当我们思考 "实体能否 对对象执行操作"这个访问控制问题时，就会发现认证和授权都是必需的，缺一不可。如果我们只对凭证进行身份验证，那么任何用户都可以对任何对象执行任何操作。我们所做的只是断言该用户在执行操作时确实是他们自己！同样，如果我们只对请求进行授权，任何用户都可以假扮成任何其他用户，对该用户的对象执行操作；我们所做的只是确保 ...