-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ApiGateway] RestApi updates account level role used for ApiGateway CloudWatch logging #10878
Comments
Indeed this is a broken experience.
Unfortunately, neither of these options will work. The APIGateway service does not provide a way to specify individual roles per API endpoint. The CDK is a stateless system and does not know what the previously value here is. I recommend setting Apologies for the poor experience. We'll need to see how to re-adjust the |
We keep running into this issue. Why should the default action be to create the role? Why not set the default for |
I agree with @gsdwait. The current default behaviour of having this option set to true is rather problematic as it overrides the global setting which applies to all APIs. This has caused a lot of headache for us in our company. Our team shares an AWS account with many other teams and suddenly our stack (which is the only CDK one currently) started overriding this role and having an impact on other teams. Please consider changing the default to false. |
Any chance this could be made the default behavior for CDK v2? There have been so many times I accidentally and silently broke logs for all my API Gateways this way. |
Just to echo this - have we missed the window to fix this for v2? Really hoping this isn't going to be a replay of #7140 (comment) ( "Since the API has been out there for a long time and our API Gateway module is stable, we cannot change this default"). |
Hi @nija-at , would you reckon the simplest option for now, before a proper solution come up in an uncertain period of time, would be that the role can be retained in the function below?
|
This behaviour is indeed very annoying and may cause that devs search for the API logs and wondering why them are nowhere to be found. Would be great if that could be fixed. |
Same here, we has this happen in our environment and silently changed the behaviour. Thankfully it was a side effect and this issue is open. There's probably a few teams out there not even realizing this behaviour is happening in their infrastructure. |
I just noticed this issue today as well... We've had this issue for over a year without even knowing it... yup, one of those teams that wasn't aware of this This affects PROD systems, I really hope this get addressed. I am testing if Also, setting a single CloudWatch Role for the entire account is not ideal and raises many other concerns. I'm surprised this is recommended. An example of this breaking a PROD system:
Now all API Gateways are using the role for the lambda function! This is dangerous for the default behavior. Update: Yes, using |
… (under feature flag) (#21546) Currently when you create a RestApi cloudwatch logging is enabled by default. This will create an IAM role and a `AWS::ApiGateway::Account` resource, which is what is used to allow API Gateway to write API logs to CloudWatch logs. There can only be a single API Gateway account per AWS environment (account/region), but CloudFormation will not throw an error if you try to create additional accounts. Instead it will update the existing account with the new configuration. This can cause issues if customers create more than 1 RestApi. The following scenario is an example. 1. Create a single `RestApi` A new `AWS::ApiGateway::Account` and IAM role is created. 2. Create a second `RestApi` Another `AWS::ApiGateway::Account`/IAM role is created which _overwrites_ the first one. The first RestApi now uses the account/role created by this `RestApi`. 3. Delete the second `RestApi` The `AWS::ApiGateway::Account`/IAM role is deleted along with the second `RestApi`. The first `RestApi` no longer has access to write to CloudWatch logs. Because of this behavior, the correct thing to do is to disable CloudWatch logs by default so that the user has to create the global resource separately. This new behavior is behind a feature flag `@aws-cdk/aws-apigateway:disableCloudWatchLogs`. In addition, the default retention policy for both the API Gateway account and IAM role has been set to `RETAIN` so that existing implementations that do not use the feature flag can avoid the above scenario. The resources will be unmanaged, but existing RestApis will not break. I've updated all the existing integration tests to use the old behavior by explicitly setting `cloudWatchLogs: true`. I then added a new integration test for the new behavior. closes #10878 ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [x] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [x] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
… (under feature flag) (aws#21546) Currently when you create a RestApi cloudwatch logging is enabled by default. This will create an IAM role and a `AWS::ApiGateway::Account` resource, which is what is used to allow API Gateway to write API logs to CloudWatch logs. There can only be a single API Gateway account per AWS environment (account/region), but CloudFormation will not throw an error if you try to create additional accounts. Instead it will update the existing account with the new configuration. This can cause issues if customers create more than 1 RestApi. The following scenario is an example. 1. Create a single `RestApi` A new `AWS::ApiGateway::Account` and IAM role is created. 2. Create a second `RestApi` Another `AWS::ApiGateway::Account`/IAM role is created which _overwrites_ the first one. The first RestApi now uses the account/role created by this `RestApi`. 3. Delete the second `RestApi` The `AWS::ApiGateway::Account`/IAM role is deleted along with the second `RestApi`. The first `RestApi` no longer has access to write to CloudWatch logs. Because of this behavior, the correct thing to do is to disable CloudWatch logs by default so that the user has to create the global resource separately. This new behavior is behind a feature flag `@aws-cdk/aws-apigateway:disableCloudWatchLogs`. In addition, the default retention policy for both the API Gateway account and IAM role has been set to `RETAIN` so that existing implementations that do not use the feature flag can avoid the above scenario. The resources will be unmanaged, but existing RestApis will not break. I've updated all the existing integration tests to use the old behavior by explicitly setting `cloudWatchLogs: true`. I then added a new integration test for the new behavior. closes aws#10878 ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [x] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [x] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This code in RestApi
aws-cdk/packages/@aws-cdk/aws-apigateway/lib/restapi.ts
Line 485 in 71aa4b6
will update the account level role for cloudwatch logging used for all ApiGateways.
The problem we are seeing is that each new API we create will replace the role used for the account with the new role created.
If the stack that last updated the account level role gets deleted for some reason then the account level role will no longer exist and all apigateway cloudwatch logging is broken for the account 😱
Reproduction Steps
What did you expect to happen?
I would expect each apigateway logging role to be only used for a given API Gateway
or I would want the apigateway account level role to be rolled back to the previous role on deletion
What actually happened?
Described above
Environment
Other
Is passing a role into each API the best option to resolve this?
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: