多云API授权面临的两大挑战
发布时间：2022-07-06 09:52:45 所属栏目：云计算 来源：互联网
导读：随着越来越多的企业采用多云战略并增加对云原生基础设施的使用，在多云环境中大规模交付API给API提供者带来了巨大压力。与此同时，无论企业采用何种云平台，API都应遵循每个公司的不同安全要求和优秀实践惯例，而这也是许多API提供者的API授权要求如此复杂的
|
随着越来越多的企业采用多云战略并增加对云原生基础设施的使用，在多云环境中大规模交付API给API提供者带来了巨大压力。与此同时，无论企业采用何种云平台，API都应遵循每个公司的不同安全要求和优秀实践惯例，而这也是许多API提供者的API授权要求如此复杂的原因。 假设在一家公司中，来自不同业务部门的多个团队正在Azure云平台中构建和部署API。在构建这些API时，不同的团队使用不同的技术(例如Azure Functions、Node.js)。同时该公司可能会托管在同一网络上使用API的应用程序，例如该公司的AWS账户或外部SaaS应用程序。 接着，我们来看看API提供者在部署和运行这些API时会面临什么挑战。 部署时间 如上所述，在多云环境中构建和部署API时，多个团队使用的技术不尽相同。因此需要一种验证API的方法来确保它们遵循优秀实践惯例。一些企业选择让其各个团队负责，希望由他们提出一些优秀实践，但这种方式通常会导致混乱。要么各个团队遵循的标准和优秀实践无法统一，要么这一过程就因为要加快交付而被忽视。另一种方式则是通过卓越中心(COE)来审查所有API并确保它们遵循优秀实践。但这种方法不可扩展，交付几个API可能适用，但在处理数千个API时，因为需要很长时间，审查就会遭遇阻碍。 很多公司希望这种流程能够自动化，作为持续集成/持续交付(CI/CD)流程的一部分自动验证API。假设每个API都使用API密钥身份验证和授权保证安全，这意味着需要采取一种方式来确保部署API之前开发人员已在API之上采用了正确的安全策略。 运行时间 在多云环境中执行授权可能会变得更加复杂，给API提供者带来严峻挑战。典型的用例情境是API提供者希望控制允许调用其API的应用程序、用户和IP范围。 存储授权数据的常用方法之一是由身份提供商(IDP)存储，并使用JWT令牌将其传递给后端API。由于这些环境的分布式特性，并可能使用不同授权技术，这种方法通常不适合多云环境。例如，AWS用户与Azure和SaaS用户使用的IDP可能不尽相同。 将用户跨多个IDP的授权数据进行复制，并使它们保持同步是复杂且低效的。API提供者在每个IDP中存储的数据也可能存在一些限制。比如，在本文的典型用例情境下，AWS的IDP管理员就会疑惑为什么他们需要存储AzureAPI的授权数据。 解决方案：声明式API授权 为了解决这个问题，可以使用带有API Ops、Kong Gateway和OPA的声明式配置。在深入探讨它们如何协同工作之前，先来了解一些基础知识。 (1)API Ops API Ops将DevOps和GitOps原则引入API和微服务生命周期，以尽可能将这些阶段自动化。通过采取声明性配置，这当中很大一部分的自动化都可实现。如果企业一直在使用Kubernetes或DevOps，那么或许已了解声明式配置的概念。使用声明性配置，API Ops可以把API生命周期的大部分自动化。 (2)开放策略代理(OPA) 开放策略代理(OPA)是一个开源策略引擎，允许用户将策略定义为代码。OPA使用Rego语言来定义这些策略。 可以使用OPA将策略创建为代码，并在其组织中的不同应用程序中执行它们，同时创建能够回答以下问题的OPA策略： 应用程序能否调用客户API? 用户X可以调用客户API吗? 用户A是否有权查看用户B的数据? OPA的声明性使其非常适合API Ops。创建这些策略，将它们存储在代码存储库中，并在API生命周期的不同阶段使用。 (3)Kong Gateway和开放策略代理 可以将OPA与Kong Gateway集成。下面来看看API使用者、Kong Gateway、OPA服务器和后端API之间的交互过程： ①API消费者向Kong Gateway发送请求。 ②Kong Gateway使用OPA插件调用OPA服务器中的策略并接收响应。 ③根据OPA服务器的响应，KongGateway判断将请求转发到后端API或返回错误。 OPA策略架构的一个重要部分是将数据与策略定义解耦。在这种情况下，策略可以通过两种方式访问它需要判断的信息： 输入：输入是指消费者向Kong Gateway发送的请求。此外还可以配置OPA插件以将网关的服务、消费者和路由对象也作为输入的一部分发送。 数据：可以使用OPA的API将任意JSON数据推送到策略中。可能有人会问为什么需要数据元素，这是因为输入是关于当前使用者的，而做判断有时需要更多信息，不仅仅是当前的用户场景。例如，任意数据可与用户角色和访问级别有关，而这在输入请求中不存在。 将外部数据注入OPA策略还有其他方法： (4)持续集成/持续交付(CI/CD)工具和开放策略代理 OPA的一大优点是它可以与大多数技术集成，只要这些技术生成和使用JSON。如今，大多数CI/CD工具都具备开箱即用的库或第三方插件来支持JSON。在部署期间，可以使用OPA来验证： 应用于API的强制Kong插件(例如，身份验证插件) 强制测试用例已经包含在项目中。 用户有权将API部署到目标环境。 在持续部署中执行声明式授权： ①API开发人员使用Insomnia设计API，定义Kong插件并将API规范检查到代码库中。 ②作为持续部署的一部分，CI/CD工具对OPA 策略进行调用。OPA策略验证API规范、Kong插件、测试用例和开发人员的授权。 ③如果结果成功，CI/CD工具继续该过程，反之停止。 (5)API Ops、Kong Gateway和OPA如何协同工作 实施此解决方案可按以下步骤： ①在将API部署到Kong Gateway之前，CI/CD工具会调用OPA，并验证强制插件是否在API定义中。如果策略检查通过，那么它会使用声明性配置来部署API。 ②消费者应用程序使用IDP或任何其他方法来创建JWT令牌。此令牌具有用户的唯一ID。在此假设用户ID在不同的云平中是唯一的。 ③消费者应用程序将请求发送到Kong Gateway。 ④Kong Gateway将请求发送到OPA服务器。OPA服务器执行策略并返回结果。 ⑤如果Kong Gateway成功，请求将发送到后端API，反之返回错误。 以下将讨论具体执行和详细内容，这里将使用GitHub Actions实现API部署自动化，读者可根据使用的CI/CD工具调整这些脚本。 如何设置GitHub操作和OPA 解决方案的第一部分是确保开发人员已在API之上纳入正确的策略。这意味着API规范中应存在密钥认证和OPA插件。 API开发人员可以使用“x-kong-plugin-”前缀将所需的插件添加到他们的API中。客户Customer API的OpenAPI规范(OAS)如下所示： 复制 openapi: "3.0.0" info: version: 1.0.1 title: customer api license: name: Kong servers: - url: ${UPSTREAM_SERVER_URL}$ description: Upstream server URL. # Key Auth plugin enables authentication for this service x-kong-plugin-key-auth: enabled: true config: key_names: - apikey x-kong-plugin-opa: enabled: true config: opa_host: ${OPA_HOST}$ opa_port: ${OPA_PORT}$ opa_path: /v1/data/userAuthz/allowUser include_consumer_in_opa_input: true include_route_in_opa_input: true include_service_in_opa_input: true 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 可以简单地创建一个OPA策略，并在API规范中查找这些插件。 复制 package apiCDAuthz default allow = false allow { input["x-kong-plugin-key-auth"].enabled == true input["x-kong-plugin-opa"].enabled == true } 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 如上可见，这一策略在OAS规范中查找这两个插件(例如输入)并检查它们是否已启用。如果两个策略都存在并启用，则返回true;否则，它返回false。 可以通过调用OPA的创建策略API创建此策略： 复制 curl -XPUT http://<opa-server:port>/v1/policies/apiCDAuthz --data-binary @./opa/apiCDAuthz.rego 1. 下一步是将OAS规范发送到OPA策略并检查结果。在这个例子中，OAS规范采用YAML编写，而OPA只能处理JSON。因此，第一步需要导出客户规范并将其转换为JSON，如下GitHub Action工作流程所示： 复制 # Export customer yaml - name: Export customer yaml run: inso export spec customer-opa --output customer.yaml # Transform OAS to JSON - uses: fabasoad/yaml-json-xml-converter-action@main id: yaml2json with: path: 'customer.yaml' from: 'yaml' to: 'json' - name: Prepare OPA input run: | cat <<EOF > ./v1-data-input.json { "input": ${{ steps.yaml2json.outputs.data }} } EOF 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 然后，可以调用OPA策略并验证JSON数据。 复制 # Check deployment authorisation - name: Call OPA to Check Deployment Authorisation id: call-opa run: | result=$(curl ${{ secrets.OPA_HOST }}/v1/data/apiCDAuthz -d @./v1-data-input.json -H 'Content-Type: application/json' | jq '.result.allow') echo "::set-output name=result::$result" - name: Should I continue? run: | if ${{ steps.call-opa.outputs.result }}; then echo "Call OPA Result: ${{ steps.call-opa.outputs.result }}" else echo "Call OPA Result: ${{ steps.call-opa.outputs.result }}" exit 1 fi 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 如果结果为false(即API规范不符合配置的优秀实践)，部署过程将自动失败，系统将通知开发人员。 此示例简单地演示了OPA在部署过程中可以发挥的作用。可以将其扩展为： 检查开发人员授权。 进行高级代码校验。 检查API优秀实践和命名约定。 如何设置Kong Gateway和OPA 如上所述，API提供者希望将其API公开给： Azure的内部使用者。 AWS的内部得到者。 使用AWS IDP的外部使用者。 使用Azure IDP的外部使用者。 与此同时，API提供者希望控制调用其API的应用程序、用户和网络。例如，API提供者可能只允许用户使用托管在公司AWS账户中的CRM应用程序调用GET客户。 API开发人员必须已在运行时为这个API配置了OPA插件。否则，它在部署过程就会失败。以下是OPA插件的配置： 复制 x-kong-plugin-opa: enabled: true config: opa_host: ${OPA_HOST}$ opa_port: ${OPA_PORT}$ opa_path: /v1/data/userAuthz/allowUser include_consumer_in_opa_input: true include_route_in_opa_input: true include_service_in_opa_input: true 1. 2. 3. 4. 5. 6. 7. 8. 9. OPA插件将请求、使用者、服务和路由信息发送到OPA服务器中的userAuthz策略。在当前请求之上添加服务、使用者和路由信息有助于访问级别更精细。例如，该策略可以限制用户仅使用某些路由。 （编辑：鞍山站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |