我们计划在项目中实施CDC,Pact被视为主要候选。目前,我正在开发一个POC,通过与GitLab的CI/CD集成来建立端到端流程。我有几个与身份验证/授权/安全相关的问题。
-
消费者契约经纪人:这里的消费者是外部合作伙伴。我认为客户端证书是一种选择。我在网上找不到太多可用选项的文档或信息。合约经纪人将托管在AWS。我们可以把它放在一个网关后面吗?
-
契约经纪人和提供者:这两个组件都是我们基础设施的一部分。在这种情况下,我知道我们将生成一个GitLab触发令牌,该令牌将作为未来请求的一部分传递给Provider管道。我们每次都会使用相同的代币。
能否告知这两种情况下的可用选项,以使通信更加安全。
提前谢谢。
我们计划在我们的项目中实施CDC,Pact被视为主要候选。
不错的选择!:(
我有几个问题与身份验证/授权/安全有关
OSS broker除了基本的auth和只读/读写访问权限之外没有任何安全控制(由于明显的原因,这不太适合外部使用(。UI中基本支持编辑凭据,但您仍然可以通过API调用获取凭据(即使是只读帐户(。
消费者合约经纪人:这里的消费者是外部合作伙伴。我认为客户端证书是一种选择。我在网上找不到太多可用选项的文档或信息。合约经纪人将托管在AWS。我们可以把它放在一个网关后面吗?
您在哪里看到支持客户端证书?很抱歉,这是不正确的。
你肯定可以把它放在网关/反向代理类型的东西后面:https://docs.pact.io/pact_broker/configuration/#running-反向氧后的经纪人
为此,您需要添加自己的身份验证层,因此使用API网关可能是一个很好的起点。
Pact Broker和Provider:这两个组件都是我们基础设施的一部分。在这种情况下,我知道我们将生成一个GitLab触发令牌,该令牌将作为未来请求的一部分传递给Provider管道。我们每次都会使用相同的代币。
提供者端身份验证与使用者端身份验证相同。
或者,我们创建了Pactflow,这是一个商业版的OSS Broker,专为企业使用而设计,它在OSS Broker上包裹了一个完整的安全模型,包括API令牌、机密、团队管理和其他有用的功能(请参阅https://pactflow.io/features/了解更多(。我们还几乎准备好了发布CI用户和细粒度权限管理。