Reputation: 43
I have a legacy api, and we are migrating the api to AWS. The api will be running on ECS Containers with a ALB.
We want use api gateway to take leverage from some features. So we created api gateway with {proxy+} Methods resources and with VPC Link Proxy Integration (Using an VPC Endpoint with a NLB pointing to our ALB)
This works using api gateway where the endpoint type is Regional. But we need have both public and private api gateway.
So our two scenarios are:
Public Scenario: Internet -> Our Public API Gateway -> VPC LINK Proxy Integration (Endpoint + NLB) -> ALB -> ECS Containers
Private Scenario: Customer VPC -> Customer VPC Endpoint -> Our Private API Gateway -> VPC LINK Proxy Integration (Endpoint + NLB) -> ALB -> ECS Containers
The problem is when we use the Authorization header we get the following response:
'hsdasneudos_dummy_token' not a valid key=value pair (missing equal-sign) in Authorization header: 'Bearer hsdasneudos_dummy_token'.
Http Status is 403 Forbidden
Response Header -> x-amzn-ErrorType: IncompleteSignatureException
The request never reach the ECS Container. This request works in Public scenario and also directly in private api gateway aws console using the test feature.
I think the problem is the Customer VPC Endpoint use Authorization header to authenticate in private api gateway, and if i use this Authorization header on my request will mess up. But This is a legacy api, we need use Authorization header.
In Private API Gateway we have resource policies to permit the Customer VPC Endpoint and the Customer VPC Endpoint also has a policy to invoke api gateway. All requests without Authorization Header works fine.
How can i solve this? The problem is what i suspect (Customer VPC endpoint uses Authorization header to authenticate)? And if it's , there are other ways for Customer VPC endpoint authenticates in api gateway without authorization header?
Thanks for any help.
Upvotes: 1
Views: 1014
Reputation: 180
I ran into the same problem. As mentioned by FDS in the other comments changing the header from Authorization
to something like AppAuthorization
did work but was clearly not a good solution.
Here is a better solution for everybody who uses CloudFormation:
Short answer
Define your policy as JSON string EXACTLY like this:
PolicyDocument: "{\n \"Statement\": [\n {\n \"Action\": \"*\", \n \"Effect\": \"Allow\", \n \"Principal\": \"*\", \n \"Resource\": \"*\"\n }\n ]\n}"
Long answer
After being in touch with AWS Support about this I figured out that the Resource Policy was the actual problem. It seems to be very picky about its format.
Originally I created it in a YAML CloudFormation template like this:
PolicyDocument:
Statement:
- Action: "*"
Effect: "Allow"
Principal: "*"
Resource: "*"
The documentation for AWS::EC2::VPCEndpoint
says that this is possible: "For CloudFormation templates in YAML, you can provide the policy in JSON or YAML format. AWS CloudFormation converts YAML policies to JSON format before calling the API to create or modify the VPC endpoint."
The mentioned conversion produces this JSON policy which DOES NOT work and causes the error:
"{\"Version\":\"2012-10-17\",\"Statement\":[{\"Action\":\"*\",\"Resource\":\"*\",\"Effect\":\"Allow\",\"Principal\":\"*\"}]}"
Even providing the resource policy as a JSON string in the CloudFormation template DOES NOT work, if the string is not formatted correctly.
In the end I reset the policy with:
aws ec2 modify-vpc-endpoint --vpc-endpoint-id vpce-01234567890abcdefg --reset-policy
And then read the policy via:
aws ec2 describe-vpc-endpoints
Then I copied the EXACT policy string into my CloudFormation template and it worked! So now it looks like this:
PolicyDocument: "{\n \"Statement\": [\n {\n \"Action\": \"*\", \n \"Effect\": \"Allow\", \n \"Principal\": \"*\", \n \"Resource\": \"*\"\n }\n ]\n}"
It cost me a lot of time to figure this out. No idea why this has to be so difficult.
Upvotes: 1