观察请求的经过：使用 APIClarity 重构 API 规范

通过观察重构 OpenAPI 规范

API 在现代微服务架构中无处不在。它们使使用来自外部应用程序的数据变得容易，并减少了开发人员需要编写的代码量。总体结果是更容易交付有用的软件产品。然而，API 的流行意味着它们代表了一个很大的攻击面。事实上，Gartner 预测，到 2022 年，API 攻击将成为企业 Web 应用程序最常见的攻击媒介。同样，IBM 的一份报告发现，三分之二的数据泄露可以追溯到错误配置的 API。

显然，企业需要采取积极主动的方法来确保他们对 API 的使用是安全的。不幸的是，由于现代应用程序的复杂性、第三方代码依赖性以及缺乏文档，API 可观察性是一个巨大的挑战。通常，企业根本没有针对其生产应用程序的任何 API 规范。结果，与安全相关的错误配置未被检测到，应用程序在生产中使用了各种已弃用的“僵尸 API”和未记录的“影子 API”。

解决此问题的基本第一步是创建 API 规范并使用它来审核和记录您的应用程序使用的 API。理想情况下，我们只需通过观察实际应用程序中的 API 流量来创建 API 规范。过去，没有简单、可扩展和开源的工具能够做到这一点。现在，我们有了APIClarity—— 一个用于 Kubernetes (K8s) 集群的开源 API 流量可见性工具。它旨在解决差距并通过观察实现 API 重建。

在这篇文章中，我们将了解什么是 API 重构以及 APIClarity 如何解决 API 可观察性问题。然后，我们将通过一个在 K8s 上运行基于微服务的应用程序来使用 APIClarity 的实际示例。

API重构的重要性

简而言之，API 重构就是通过观察进出该 API 的流量来构建 API 规范。如果做得好，API 重建可以让您了解微服务使用的 API，并让您能够评估 API 安全风险。构建规范后，相同的工具可以将运行时流量与规范进行比较以检测偏差。

API 规范的关键组成部分包括：

• 参数检测（路径、头部参数、查询参数、请求体参数、cookies）
• 对象引用
• 文件传输
• 安全定义

理想情况下，API 重构工具需要以符合 OpenAPI 规范 (OAS) 的格式量化这些组件，而不会给应用程序带来不必要的开销或复杂性。在 APIClarity 之前，有几个工具可以部分解决 API 重构用例，但没有全面的开源解决方案。API 可见性的其他一些工具包括：

• Optic — 一种可扩展的、与语言无关的开源工具。它对于在部署之前记录、审查和批准 API 很有用。
• SwaggerHub — 一种将 API 流量转换为 OAS 的流行工具。
• CloudVector API Shark — 可以监控多服务环境并从运行时流量生成 OAS 规范。
• Imvision — 适用于多服务环境的强大 API 可见性和文档工具。

Optic 不是为监控多服务环境而构建的，SwaggerHub 也不与运行时环境集成。API Shark 和 Imvision 都不是开源的。以上工具均不能完全满足 API 重构的需求。

APIClarity 如何解决 API 重构和可见性挑战

APIClarity 填补了其他工具留下的空白，并提供了强大、开源和可扩展的多服务 API 可见性和重构解决方案。它使用服务网格框架轻松集成到现有环境中。使用 APIClarity，开发人员可以导入 API 规范或根据观察重新构建 API 规范。开发人员还可以实时监控所有 API 流量，无需更改代码或工作负载。

那么它是怎样工作的？

图片来源

• APIClarity 部署在现有的 K8s 集群中
• API 流量从集群中的 pod 镜像到 APIClarity 的 OpenAPI Spec Engine
• 规范引擎监控内部和外部流量并记录 API 事件
• APIClarity 根据 API 流量学习规范并构建 API 规范
• 用户审查、编辑和批准规范
• APIClarity 提醒用户注意安全问题或观察到的 API 与批准的 API 规范之间是否存在任何偏差

APIClarity 在行动：演练

现在我们知道 APIClarity 是什么，让我们深入了解我们的教程，看看它在 K8s 集群和基于微服务的应用程序中的作用。在这里，我们将：

1. 在我们的 K8s 集群中部署Sock Shop 应用程序。虽然我们将使用 Sock Shop 作为我们的示例应用程序，但您可以将自己的应用程序部署到您的集群并继续跟进。
2. 在我们的 K8s 集群中部署 APIClarity 并配置监控
3. 在 APIClarity 仪表板上观察 API 流量
4. 查看并创建 API 规范，并以 Swagger 格式查看生成的 OpenAPI 规范。
5. 识别与 API 规范的偏差以及影子和僵尸 API 的使用。
6. 查看和过滤 API 事件

先决条件

要继续学习，您需要：

• 具有默认 StorageClass 定义的 Kubernetes 集群
• Istio 1.10 以上，安装在集群上

您的 K8s 集群可以部署在您喜欢的任何平台上，包括 minikube。虽然 APIClarity 支持代理 API 流量的多种集成，但您需要下载并安装 Istio。

在您的 K8s 集群中部署 Sock Shop 应用程序

我们将使用流行的Sock Shop 微服务应用程序作为我们的测试应用程序。它拥有 14 种不同的微服务和一个交互式前端，是在 K8s 集群中测试 API 流量的好方法。

1）创建sock-shop命名空间。

kubectl 创建命名空间袜子店

2) 为命名空间启用 Istio 注入sock-shop。

kubectl 标签命名空间 sock-shop istio-injection=enabled

3) 在集群中部署 Sock Shop 演示应用程序。

kubectl apply -f https://raw.githubusercontent.com/microservices-demo/microservices-demo/master/deploy/kubernetes/complete-demo.yaml

4) 获取front-end服务的 NodePort。

kubectl 描述 svc 前端 -n sock-shop | grep 节点端口：

输出应如下所示：

节点端口：                  <未设置>   30001 / TCP

5)http://<node_IP>:<NodePort>在浏览器中连接。使用我们上面的例子，如果我们节点的 IP 是 192.168.49.2，浏览到http://192.168.49.2:30001. 如果您不知道您的节点的 IP，您可以使用kubectl get nodes -o yaml或进行验证minikube ip。如果一切正常，Sock Shop 演示应用程序应该会加载。

在我们的 K8s 集群中部署 APIClarity 并配置监控

首先，我们需要在集群中部署 APIClarity。

1) 我们首先将 GitHub 存储库克隆到我们的主目录：

光盘~

git 克隆 https://github.com/apiclarity/apiclarity

2) 接下来，导航到apiclarity目录。

cd 尖度

3)kubectl用于部署 APIClarity。使用默认的 apiclarity.yaml，命名空间将为apiclarity.

kubectl apply -f 部署/apiclarity.yaml

4) 确认 pod 正在运行。

kubectl 获取 pods -n apiclarity

输出应如下所示：

名称                          就绪   状态    重新开始   年龄

尖度- 679949 b687 - x25pb    1 / 1     运行   0           16 m

apiclarity - postgresql - 0        1 / 1     运行   0           16 m

5）初始化和更新wasm-filters子模块：

git submodule init wasm-filters

git 子模块更新 wasm-filters

6）导航到wasm-filters文件夹：

cd wasm 过滤器

7) 运行 wasm./deploy.sh脚本，以便 Envoy Wasm 过滤器可以捕获来自 Sock Shop 的流量。该脚本接受多个命名空间作为输入参数，例如./deploy.sh <namespace_one> <namespace_two> <namespace_three>，但是对于这个演示，我们只需要指定sock-shop命名空间。

./deploy.sh 袜子店

8) 为 APIClarity 配置端口转发。

kubectl 端口转发 -n apiclarity svc/apiclarity 9999:8080

9) 使用网络浏览器连接到 APIClarity GUI，位于http://localhost:9999.

在 APIClarity 仪表板上观察 API 流量

现在，是时候产生流量了。首先单击 Sock Shop 应用程序中的不同按钮和菜单。

• 专业提示：API 流量越多越好！更多流量 = 更多观察 = 更深的可见性。对于我们演示的这一部分，我们只需要一点流量，但在生产时请牢记这一原则。

在 Sock Shop 中生成一些 API 流量后，返回 APIClarity 仪表板。您会注意到 APIClarity 记录了所有不同的 API 调用。在下面的示例中，我们可以看到对catalogue端点的 17 次调用、对 的 8 次调用carts和对 的 3 次调用user。我们还可以看到 APIClarity 如何开始绘制 API 使用情况。在我们产生更多流量并创建我们的 API 规范之后，这些图表将变得更加有趣和有用。

在 Swagger 中查看和创建 API 规范并查看文档

现在，让我们根据我们拥有的相对较少的流量创建一个 API 规范。

1) 单击“最常用的 API”之一。我会用catalogue.

2) 单击“重建”选项卡，然后单击“审查”。

3）在这里，我们可以查看API路径，添加参数，合并条目。我将添加一个example_param并审查和批准路径。随意在这里尝试您的选择。

4) 现在，我们有了一个 OAS API 规范。我们可以直接从 APIClarity GUI 查看 Swagger 中的 API 文档。

识别与 API 规范的偏差

现在我们有一个 API 规范作为基线，APIClarity 可以标记与规范的偏差，以帮助检测安全问题和影子 API。要了解它是如何工作的，请返回 Sock Shop GUI 并进行更多试验。单击您上次未使用的某些功能或过滤器。如果您创建了订单，请将其删除。这里的关键是执行一些不在规范中的操作。这些将被识别为“差异”。

例如，在这里我多次调用catalogue与我的规范不匹配的端点：

我们可以通过单击特定的差异来深入了解与规范的不同之处。在这里，我们可以看到检测到偏差，因为我的 API 调用缺少一些参数。

这是一个记录在案的 API 调用示例，其参数与规范不同。但是，如果 API 调用根本没有记录在规范中怎么办？在这种情况下，APIClarity 会将其标记为影子 API。

这正是对carts路径的 API 调用所发生的情况。在我们创建规范时，我们只观察到一个 GET 和一个 POST，所以这就是记录的内容。因此，DELETE 调用超出了规范并标记为影子 API。

正如您所料，这是一个合法的 API 调用，我应该记录在案。这个场景为我们提供了一个实际示例，说明为什么在创建 API 规范之前让 APIClarity 捕获大量流量很有用。

查看和过滤 API 事件

我们还可以使用 APIClarity 查看和过滤 API 事件。

要查看事件，请单击事件图标：

在这里，您将看到给定时间段内所有 API 事件的详细列表（“最后一天”是默认设置）。我们还可以像在仪表板中那样深入查看各个事件：

此外，您可以应用高级过滤器来搜索特定的 API 事件。例如，我们可以通过应用Spec of type is shadow过滤器创建 APIClarity 观察到的所有影子 API 调用的列表。

僵尸 API 的检测与此类似。我们将修改过滤器以查找Spec of type is zombie. 如果我们的调用之一是对我们规范中已弃用的 API 的调用，那么我们会在此处看到它。

您可以混合和匹配过滤器并对结果进行排序以实现各种不同的视图。这样，您可以深入了解应用程序中的 API 事件。

最后的想法

作为一个开源项目，APIClarity 不断发展并接受来自开发者社区的贡献。

我希望你喜欢这个演练！我们在这里只触及了表面，有几个有趣的用例用于 API 重建和使用 APIClarity 进行流量监控。除了提高 API 可见性和安全性之外，它还支持模糊测试、客户端/服务器代码生成以及改进内部和面向用户的文档等用例。