0

我们计划在我们的项目中实施 CDC，Pact 被视为主要候选者。目前，我正在开发一个 POC，以通过与 GitLab 的 CI/CD 集成来设置端到端流程。我有几个与身份验证/授权/安全相关的问题。

  1. 消费者 - Pact Broker：这里的消费者是外部合作伙伴。我认为客户端证书是一种选择。对于可用选项，我无法在 Web 上找到太多文档或信息。Pact 代理将托管在 AWS 中。我们可以把它放在网关后面吗？

  2. Pact Broker 和 Provider：这两个组件都是我们基础架构的一部分。在这种情况下，我知道我们将生成一个 GitLab 触发器令牌，它将作为未来请求的一部分传递给 Provider 管道。我们每次都将使用相同的令牌。

您能否建议两种情况下可用的选项，以使通信更加安全。

提前致谢。

4

1 回答 1

0

我们计划在我们的项目中实施 CDC，Pact 被视为主要候选者。

好的选择！:)

我有几个与身份验证/授权/安全相关的问题

OSS 代理除了基本身份验证和只读/读写访问权限外没有任何安全控制（出于显而易见的原因，这不太适合外部使用）。UI 中提供了对编辑凭据的基本支持，但您仍然可以通过 API 调用获取它们（即使对于只读帐户也是如此）。

消费者 - Pact Broker：这里的消费者是外部合作伙伴。我认为客户端证书是一种选择。对于可用选项，我无法在 Web 上找到太多文档或信息。Pact 代理将托管在 AWS 中。我们可以把它放在网关后面吗？

您在哪里看到支持客户端证书？我很抱歉说这是不正确的。

你绝对可以把它放在网关/反向代理类型的东西后面：https ://docs.pact.io/pact_broker/configuration/#running-the-broker-behind-a-reverse-proxy

为此，您需要添加自己的身份验证层，因此为此使用 API 网关可能是一个很好的起点。

Pact Broker 和 Provider：这两个组件都是我们基础架构的一部分。在这种情况下，我知道我们将生成一个 GitLab 触发器令牌，它将作为未来请求的一部分传递给 Provider 管道。我们每次都将使用相同的令牌。

提供方身份验证与消费者相同。

或者，我们创建了 Pactflow，它是 OSS 代理的商业版本，专为企业使用而设计，具有完整的安全模型，包含在 OSS 代理上，包括 API 令牌、机密、团队管理和其他有用的功能（请参阅https:// pactflow.io/features/了解更多信息）。我们也几乎准备好发布CI 用户和细粒度的权限管理。

于 2020-09-08T00:02:55.380 回答