AWS::CodeStarNotifications::NotificationRule - Drift detection false-positive once adding stack-level tags

rgoltz commented 2 years ago

Name of the resource

AWS::CodeStarNotifications::NotificationRule

Resource Name

No response

Issue Description

Once you create add tags on stack-level and your stack containing a AWS::CodeStarNotifications::NotificationRule, the CloudFormation drift detection reporting such stack as drifted (details see "Observed Behavior").

Expected Behavior

AWS::CodeStarNotifications::NotificationRule has tags from stack
CloudFormation drift detection understand this and does not report this as drift

Observed Behavior

Once you adding Stack-Level-Tags your AWS::CodeStarNotifications::NotificationRule is marked as drifted.

Test Cases

1) create a new stack with this template (along with step 2)- here in my test-case in region eu-central-1:

---
AWSTemplateFormatVersion: '2010-09-09'
Description: Stack with Tagged CodeStarNotifications - case 10851630161

Resources:
  CodeStarNotificationWithTagsFromStack:
    Type: AWS::CodeStarNotifications::NotificationRule
    Properties:
      Name: 'rogoECS-Sandbox-Pipeline-TestRuleTagViaStack1'
      DetailType: FULL
      Resource: 'arn:aws:codepipeline:eu-central-1:<ACCOUNTID>::AwsECS-Sandbox-Pipeline'
      EventTypeIds: 
        - codepipeline-pipeline-pipeline-execution-succeeded
      Targets: 
        - TargetType: SNS 
          TargetAddress: 'arn:aws:sns:eu-central-1:<ACCOUNTID>:Some_Email_Notification'

2) during create please add tags to the stack: github_addTags

3) after creation is finished, please run drift detection. You should see this result: github_drift

Other Details

I was not able to check, if this stack-based tags are applied to AWS::CodeStarNotifications::NotificationRule
There was an other (resolved) issue related this this case here: https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/1223

kanitkah commented 1 year ago

We are looking into this issue currently.

kanitkah commented 1 year ago

Can you retry the scenario and let us know if the issue is resolved?

rgoltz commented 1 year ago

@kanitkah Harshu, thanks a lot for keep us in the loop and reporting the progress here. I've re-run two test-case in eu-central-1:

a) creating a new stack with AWS::CodeStarNotifications::NotificationRule + adding stack-level tags during initial creation
b) checking an existing stack with AWS::CodeStarNotifications::NotificationRule which has stack-level tags in place

Unfortunately both stacks still showing a drift after running a fresh Drift Detection in our accounts in eu-central-1. In case you like to take a look, I've shared the stack ARN via case 11972399991. May it would take some more time until the fix is deployed to eu-central-1 / getting active in our AWS accounts? - I'm at your disposal to re-run the tests at any time required.

kanitkah commented 1 year ago

Thanks for the feedback and additional info. We are taking a look and will get back to you.

rgoltz commented 1 year ago

Re-Test today:

Running a new Drift Detection on an existing stack results still in state DRIFTED.
Creating a new stack/resource and running a Drift Detection against them, it's in state IN_SYNC.

I've changed one stack-level-tag as a "dummy change" in anticipation that would change the setting for existing stacks (at least for the AWS::CodeStarNotifications::NotificationRule resource), but it did not. A new Drift Detection run still showing those stacks in state DRIFTED.

kanitkah commented 1 year ago

HI Robert, can you retry this scenario now? We pushed out a fix yesterday and cannot reproduce the issue anymore. @rgoltz

rgoltz commented 1 year ago

I'll retry today and let you know my results here :)

rgoltz commented 1 year ago

@kanitkah - Testing-Summary:

(a) Re-Run Drift Detection for existing Stacks with stack-level tags => DRIFTED

(b) Changing Value of one (1) random/existing stack-level tag and update stack => still DRIFTED

(c) Remove all (!) stack-level tags + update stack (hence have no stack-level-tags anymore) & re-add all (!) stack-level again + update => IN_SYNC

That's the way users have to follow for existing stacks with AWS::CodeStarNotifications::NotificationRule + Stack-Level-Tags to resolve the drift-issue?
What was your scenario for testing, since you didn't reproduce the issue anymore? Testing in eu-central-1 with existing stacks?

PS: all my testing done in eu-central-1

kanitkah commented 1 year ago

Hi Robert, the deployed fix applies for new CodeStar NotificationRule resources, and also for existing ones if they are updated with new stack-level tags. Here are some options for next steps for any customers still facing stack-level tag drift on this particular resource: 1) Directly adding the expected stack-level tags to the individual CodeStar NotificationRule resource, via the AWS CLI or SDK. 2) Removing and re-adding the stack-level tagging to the CloudFormation stack, which will update the existing CodeStar NotificationRule resource with new stack-level tags.

Seems like you have already gone through the steps for option 2. Apologies, as I should have mentioned this in my previous post.

aws-cloudformation / cloudformation-coverage-roadmap