将现有 API 密钥与 AWS 中的无服务器框架结合使用 [英] Using an existing API key with the Serverless Framework in AWS

问题描述

在 serverless.yml 文件中，您可以指定要与已部署 API 中的函数一起使用的 API 密钥的名称.您列出 API 密钥名称，然后将您希望使用它保护的方法标记为私有.例如:

In the serverless.yml file you can specify the name of an API key to use with functions in the deployed API. You list the API key name(s), and then mark the methods you wish to secure with it as private. For example:

provider:
  name: aws
  runtime: nodejs4.3
  cfLogs: true
  apiKeys:
    - MyAPIKey

部署后，框架生成 API 密钥并将其分配给函数.即使环境中已经存在同名密钥，它也会生成密钥.

Upon deploy, the framework generates the API key and assigns it to the functions. It generates the key even if one with the same name already exists in the environment.

有没有办法指定现有的 API 密钥，而不是让框架生成它?我们真的希望继续生成与部署分开的密钥.

Is there a way to specify an existing API key, rather than have the framework generate it? We really wish to keep generating the key separate from deployments.

推荐答案

我知道这是旧的，但我最近遇到了这个问题并解决了它，所以我想我会把我找到的东西放在这里.

I know this is old, but I've had this problem recently and solved it, so I thought I'd put what I found here.

这个答案基于这个论坛帖子，我需要一些上下文才能开始工作:https://forum.serverless.com/t/using-an-existing-api-key/770

This answer is based on this forum post, which required a bit of context for me to get working: https://forum.serverless.com/t/using-an-existing-api-key/770

使用资源部分，可以将自定义 CloudFormation 配置添加到您的部署中.这包括添加启用特定 api 密钥的自定义使用计划:

Using the resources section it is possible to add custom CloudFormation configs into your deployment. This includes adding in a custom usage plan with specific api keys enabled:

https://serverless.com/framework/docs/providers/aws/指南/资源/

结构大致如下，下面有说明:

The structure is roughly as follows, with explanations below:

resources:
  Resources:
    MyServiceUsagePlan:
      Type: "AWS::ApiGateway::UsagePlan"
      DependsOn: ApiGatewayRestApi
      Properties:
        UsagePlanName: ${self:service}-${self:provider.stage}-usagePlan
        Quota:
          Limit: 10000
          Offset: 0
          Period: DAY
        Throttle:
          BurstLimit: 20
          RateLimit: 10
        ApiStages:
          -
            ApiId:
              Ref: ApiGatewayRestApi
            Stage: ${self:provider.stage}

    MyServiceKey:
      Type: "AWS::ApiGateway::UsagePlanKey"
      DependsOn: MyServiceUsagePlan
      Properties :
        KeyId: ${file(./conf/${self:provider.stage}.yml):MyServiceKeyId}
        KeyType: API_KEY
        UsagePlanId:
          Ref: MyServiceUsagePlan

这些资源中的每一个都以您提供的密钥命名.无服务器为您提供无服务器生成的资源名称的名称，以防您希望覆盖它们的一部分或引用它们.不过，您几乎可以为它们命名任何名称，只要它符合 CloudFormation 命名要求即可.

Each of these Resources are named after the key you give them. Serverless gives you the name of the serverless-generated Resource names in case you wish to overwrite parts of them or reference them. You can name them pretty much anything, though, as long as it matches CloudFormation naming requirements.

无服务器确实添加了一些变量:

Serverless does add a few variables, though:

• DependsOn:这意味着具有引用的资源按名称进行.上面的无服务器文档链接列出了在您想要引用非自定义资源时使用的标准命名约定.例如，ApiGatewayRestApi"是无服务器在所有带有 http 事件的部署中创建的标准 API.
• Ref:对堆栈中另一个对象的引用.在上面的示例中，它取代了显式传递 ApiId 或 UsagePlanId(将在堆栈创建时生成或检索)的需要.这意味着您可以设置对堆栈中事物的依赖关系，而无需记录 ID.
• 配额和限制:可选.忽略这些将避免更新引用的使用计划.

• DependsOn: This means that the resource with References are by name. The serverless doc link above lists the standard naming conventions that are used in case you want to reference non-custom resources. For example, "ApiGatewayRestApi" is the standard api created by serverless in all deployments with http events.
• Ref: A reference to another object in the stack. In the above example, it replaces the need to explicitly pass an ApiId or UsagePlanId (which will be generated or retrieved on stack creation). This means you can set up dependencies on things within your stack without needing to record Ids.
• Quota and Throttle: optional. Leaving these out will avoid updating a referenced usage plan.

另外，关于使用计划和使用计划密钥的一些行为:

Additionally, some behaviour about usage plans and usage plan keys:

• 使用计划一旦生成一次，将在部署之间保留其 UsagePlanId，即使您更改了计划名称(通过 UsagePlanName).我的测试是，在无服务器部署之外创建的 UsagePlanKeys 不会在更新时删除，但我还没有进行足够广泛的测试，无法 100% 确定.
• 可以在 API 部署范围之外创建使用计划，并使用 UsagePlanId 变量进行引用.

您可能有兴趣在任何一个 api 部署之外创建您的身份验证结构，并使用 CloudFormation 的(通过无服务器)输出服务来获取您创建的每个资源的 ARN 和/或 ID:

You may be interested in creating your auth structure outside of any one api deployment and using CloudFormation's (via Serverless) Outputs service to get the ARN and/or ID of each of the resources you've created:

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html

输出使用与资源相同的格式，可以在示例 aws serverless.yml 中看到一个示例.这将允许您独立于 API 本身更改使用计划并单独维护.您可以保存这些输出以供 api 使用，使用 javascript 变量引用仅添加应在每个阶段、每个 api 基础上启用的计划.

Outputs uses the same format as Resources and an example can be seen in the example aws serverless.yml. This will allow you to change the usage plans independent of the apis themselves and maintain that separately. You can save those outputs for use by your apis, using a javascript variable reference to add only the plans that should be enabled on a per-stage, per-api basis.

tl;dr - 使用资源结构制作原始 CloudFormation 配置.

tl;dr - Use the resources structure to make raw CloudFormation configs.

• 资源使您能够引用现有的密钥、计划和其他资源.
• Outputs 可让您接收和保存您可能希望跨部署使用的对象的标识符.
• 更新对象不会删除在堆栈之外创建的关联(我已经能够看到)，因此将外部密钥添加到您以这种方式创建的使用计划中是安全的.

这篇关于将现有 API 密钥与 AWS 中的无服务器框架结合使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！