Open jasonlim-bandlab opened 3 days ago
Hey @jasonlim-bandlab, sorry you're running into this issue!
Could you please attach a code example that helps us reproduce this? Thanks!
@flostadler
args.routes.map((route) => {
new awsNative.lambda.Permission(`${name}-permission-${route.method}-${route.path}`, {
action: "lambda:InvokeFunction",
functionName: route.handlerFunction.lambdaFunction.functionName.apply((name) => name || ""),
principal: "apigateway.amazonaws.com",
sourceArn: pulumi.interpolate`arn:aws:execute-api:${args.region}:${args.accountId}:${this.api.apiId}/*/${route.method}${route.path}`,
});
const routeIntegration = new awsNative.apigatewayv2.Integration(`${name}-${route.method}-${route.path}`, {
apiId: this.api.apiId,
integrationType: "AWS_PROXY",
integrationUri: route.handlerFunction.lambdaFunction.arn,
integrationMethod: route.method,
payloadFormatVersion: "2.0",
});
new awsNative.apigatewayv2.Route(`${name}-route-${route.method}-${route.path}`, {
apiId: this.api.apiId,
routeKey: `${route.method} ${route.path}`,
target: pulumi.interpolate`integrations/${routeIntegration.integrationId}`,
authorizerId: route.isPublic ? undefined : authorizer.authorizerId,
authorizationType: route.isPublic ? undefined : "JWT",
});
});
This snippet above shows how each defined route is provisioned. I believe the authorizerId
and authorizationType
under apigatewayv2.Route
might be of particular interest to you.
@flostadler ,
Due to the failure in detachment, the authorizer cannot be removed because it remains attached.
@jasonlim-bandlab do any errors occur when trying to remove the authorizer? I assume pulumi is showing that it's removing it, but the physical cloud resources still has it attached? Generally, please attach error messages as text so it's easier for the maintainers to work with.
As a workaround you could try using the @pulumi/aws
provider: https://www.pulumi.com/registry/packages/aws/api-docs/apigatewayv2/
@jasonlim-bandlab the issue is that you're setting the authorizationType
of the route to undefined
. AWS CloudFormation and AWS CloudControl, which this provider is built on, have a quirk that in order to remove the authorizer, you need to set the type to NONE
instead.
I was able to repro your problem with this program (also edited the issue to the full repro instead):
import * as pulumi from "@pulumi/pulumi";
import * as awsNative from "@pulumi/aws-native";
const api = new awsNative.apigatewayv2.Api("my-api", {
protocolType: "HTTP",
})
const authorizer = new awsNative.apigatewayv2.Authorizer("my-authorizer", {
apiId: api.apiId,
authorizerType: "JWT",
identitySource: ["$request.header.Authorization"],
name: "my-authorizer",
jwtConfiguration: {
audience: ["https://github.com/pulumi"],
issuer: "https://token.actions.githubusercontent.com",
},
});
const routeIntegration = new awsNative.apigatewayv2.Integration("test", {
apiId: api.apiId,
integrationType: "HTTP_PROXY",
integrationUri: "https://example.com/{proxy}",
integrationMethod: "ANY",
payloadFormatVersion: "1.0",
});
new awsNative.apigatewayv2.Route("test", {
apiId: api.apiId,
routeKey: "ANY /example/{proxy+}",
target: pulumi.interpolate`integrations/${routeIntegration.integrationId}`,
authorizerId: authorizer.authorizerId,
authorizationType: "JWT",
});
removing the authorizerId
& authorizationType
left the authorizer attached to the route, but when doing this instead it got correctly removed:
...
new awsNative.apigatewayv2.Route("test", {
apiId: api.apiId,
routeKey: "ANY /example/{proxy+}",
target: pulumi.interpolate`integrations/${routeIntegration.integrationId}`,
authorizationType: "NONE",
});
That being said, I agree that this is unexpected as do users in other ecosystems, see: https://github.com/aws/aws-cdk/issues/20695. I'll send an enhancement request to AWS and keep this issue open for a docs enhancement on our side.
Opened issue with AWS: https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/2184
@flostadler, oh, thanks! It's working as expected now. I appreciate the tips and the effort in opening the ticket. Since my issue is resolved, should I go ahead and close it, or would it be better to wait for updates from AWS?
@jasonlim-bandlab let's keep it open. We should at least document this quirk on our end for now
What happened?
Based on the image above, we attempted to remove both
authorizationType
andauthorizerId
, expecting the route to detach the authorizer. However, upon checking in the console, the authorizer still appears to be attached. I might be missing something or doing it incorrectly. Could you please guide me on the correct steps to properly detach the authorizer from the route?Example
Output of
pulumi about
Version 3.121.0 Go Version go1.22.4 Go Compiler gc
Plugins KIND NAME VERSION resource aws 6.56.1 resource aws-native 1.7.0 language nodejs unknown resource random 4.16.7
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).