API Gateway Resource Policy

[brettstack]

Resources:

https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-restapi.html#cfn-apigateway-restapi-policy

Amazon API Gateway resource policies are JSON policy documents that you attach to an API to control whether a specified principal (typically an IAM user or role) can invoke the API. You can use API Gateway resource policies to allow your API to be securely invoked by:

• users from a specified AWS account

• specified source IP address ranges or CIDR blocks

• specified virtual private clouds (VPCs) or VPC endpoints (in any account)

Resources:
  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      ...
      Auth:
        ResourcePolicy:
          # IAM-based policies
          IAMAllowlist: [
          '123456789012:role/myRole',
          '${AWS::AccountId}:user/myUser',
          '123456789012:root',
          '123456789012:*'
          ],
          IAMDenylist: [],

          # IP-based policies
          IpAllowlist: ['12.123.234.213'],
          IpDenylist: [],

          # VPC-based policies
          SourceVpcAllowlist: ['vpc-ab1234cd'],
          SourceVpcDenylist: []

          # Custom statements. These must be actual Resource Policy Statements.
          CustomStatements: [{
            Action: 'execute-api:Invoke', # Optional; Default: execute-api:Invoke
            Resource: ['execute-api:/*/*/*'], # Optional; constructed based on Stagename, Path, and Method.
            ... # Additional properties get passed through to the resulting statement
          }]

  MyFn:
    Type: AWS::Serverless::Function
    Properties:
      Events:
        GetRoot:
          Type: Api
          Properties:
            Auth:
              ResourcePolicy:
                ... # Same as above; the Statement Resource will be created differently when defined here (i.e. it will use the Method and Path)

When Auth.ResourcePolicy is set on an API Event, the Path and Method of the Event will be used to construct the Resource. When Auth.ResourcePolicy is set on an API resource, the Path and Method parts of Resource will be *; that is, the policy will apply to the entire API. For the Stage part of Resource, we can inject the StageName, however, we do need to consider how we will make it work when we implement multi-stage support.

Note that Event ResourcePolicy and API Resource ResourcePolicy are combined to create the final ResourcePolicy.

[SanderKnape]

What is the status of implementing this feature? We could really use this to start working with private API Gateway endpoints.

[bigunyak]

Just stumbled on this problem as well. Had to use x-amazon-apigateway-policy extension to get my API Gateway resource policies work.

[tkeeber]

Anyone update on this one? Trying to grant access to a API Gateway using a IP whitelist is overly difficult right now.

[createdon2003]

Just stumbled on this problem as well. Had to use x-amazon-apigateway-policy extension to get my API Gateway resource policies work.

Can you share your SAM template with x-amazon-apigateway-policy in it. I am facing difficulty in getting it to work. For some reason final cloud formation does not have any resource policy attached.

[spezam]

@createdon2003, it should be something like this:

  anAPI:
    Type: AWS::Serverless::Api
    Properties:
      Name: an-api
      StageName: api
      EndpointConfiguration: PRIVATE
      DefinitionBody:
        swagger: 2.0
        info:
          title: !Ref AWS::StackName
        x-amazon-apigateway-policy:
          Version: "2012-10-17"
          Statement:
            - Effect: "Allow"
              Principal:
                AWS: !Sub "arn:aws:iam::${AWS::AccountId}:root"
              Action:
                - "execute-api:Invoke"
              Resource: !Sub "arn:aws:execute-api:eu-west-1:${AWS::AccountId}:vc9kk3ltoi/*"
              Condition:
                StringEquals:
                  aws:sourceVpce: !Ref VpcEndpoint
        paths:
...

[verzac]

Hi team, any update on this one? Is it still RFC? Keen on having resource policies as part of SAM templates.

This would be especially useful for us because we want to have a custom WAF in front of our API GW, and would like to have our API GW only accept traffic from that WAF.

[brettstack]

As a first pass for this feature, we should just do the Auth.ResourcePolicy.CustomStatements implementation. The [IAM|Ip|SourceVpc][Allow|Deny]List features are syntactic sugar. This would be a good first issue.

1. Check if ResourcePolicy property exists on Authlike we do here for checking Authorizers https://github.com/awslabs/serverless-application-model/blob/cbd4d9ad40a71b838f1e72b3b960689f30890bf9/samtranslator/model/api/api_generator.py#L242. If it exists, call swagger_editor.add_resource_policy(resource_policy)
2. Add add_resource_policy method here https://github.com/awslabs/serverless-application-model/blob/cbd4d9ad40a71b838f1e72b3b960689f30890bf9/samtranslator/swagger/swagger.py#L289. This should check if CustomStatements exists on resource_policy and that it is an Array (bonus points for allowing both an Array of Dict or a single Dict (use case where you just want to define a single Statement)). After that validation, add the statements to self._doc["x-amazon-apigateway-policy"].Statement and set Version: "2012-10-17"

[markstos]

Is there a workaround if this feature is not available? I want to use serverless to publish a Lambda/API-Gateway pair that can only be called some specific security groups in my VPC.

[jlhood]

@markstos The current workaround is to hand-manage the swagger definition of the serverless API.

[jlhood]

Also want to reiterate @brettstack's #514 (comment) that a first-pass fix of this issue is actually a pretty simple targeted fix. If someone from the community wants to step up and take it, that would be terrific!

[markstos]

@jlhood I'll take a look at this. At this point, I invested time in the serverless approach, so I can either spend some time on the fix I need, or spend time backing out of the serverless approach.

[jlhood]

@markstos Thank you!

[markstos]

Getting setup just to contribute to this project is enough of a pain that I think I'll just give up on converting the server I had in mind to the serverless model. Here's a snapshot of what I experienced:

make install asks me to remove the .pyenv directory:

$ make install
[*] Install pyenv using https://github.com/pyenv/pyenv-installer/raw/master/bin/pyenv-installer...

WARNING: Can not proceed with installation. Kindly remove '.pyenv' from /home/mark first.

So I remove the directory and try again:

 $ make install
Makefile:13: *** "make sure pyenv is accessible in your path, (usually by adding to PATH variable in bash_profile, zshrc, or other locations based on your platform) See: https://github.com/pyenv/pyenv#installation for the installation insructions.".  Stop.

pyenv has been installed in ~/.pyenv/bin, which is where it is recommended to be installed:
https://github.com/pyenv/pyenv#installation

So: Catch-22! Whether I try to install pyenv manually (into ~/.pyenv/bin or with make install, it fails either way.

Meanwhile, Ubuntu provides a package which installs a binary that sounds like it would the same, but isn't: pyvenv.

I'm a deadline to update a Ubuntu 14.04 server to 18.04 before the April 17th, EOL date, so it's unlikely I'll come back to this.

[jlhood]

@markstos I'm sorry you had a bad experience trying to get setup to contribute to SAM. Did you follow the instructions in the Development Guide? That has detailed instructions on how to get setup. You shouldn't need to run make install.

[pablosjv]

I have been using SAM for a couple of months and it's been great. I think this feature will be very useful in the development process of serverless applications.
Is there anyone currently working in the implementation of this? I would like to help :)

[jlhood]

@pablosjv By all means, we'd love for you to contribute! @brettstack summarized the 1st pass changes needed to support this feature in this comment: #514 (comment)

Follow the development guide to get setup and we look forward to reviewing your PR! 😊

[BaconAndEggs]

Thank you much for the excellent framework and tooling!

My team has a project where we are implementing a private REST API. We recently considered the benefits and drawbacks available via swagger/openapi import definition model and the definition of our API directly using the AWS::Serverless::Function definition and having SAM render the API gateway via the implicit logic. We decided to go the AWS::Serverless::Function definition route.

To workaround this issue, we added CI/CD logic to render a resource policy and using an API Gateway create_deployment call.

Since last week (I believe May 9th 2019), in us-west-1, when running new test environment deployments, I found that the workaround of applying a resource policy after deployment is not viable there, because CloudFormation enforces that a resource policy must have a resource policy configured to complete deployment. I don't see the same behavior in us-east-1 or us-east-2.

As an example, if I use the SAM CLI and init a new SAM project, and add these 2 lines to the default template.yaml Globals section:

  Api:
    EndpointConfiguration: PRIVATE

when I run a deployment of that default template (altered to configure a private API) to us-west-1 the create stack reaches a rollback complete with the initial error event being:

Private REST API doesn't have a resource policy attached to it (Service: AmazonApiGateway; Status Code: 400; Error Code: BadRequestException; Request ID: xxxxxxxxxxxxxxxxxxxxxxxxxx)

[keetonian]

@BaconAndEggs Thank you for reporting this issue! I created a new issue out of your comment, please post in #925 if you see any additional errors. We will see if we can find out any more information about this issue.

[KrausMatthias]

I got it to work like this: https://serverless.com/framework/docs/providers/aws/events/apigateway#resource-policy

[ShreyaGangishetty]

Closing this issue as v1.15.0 is released