AWS::EC2::SecurityGroup - BUG - cross-account Security Group Id reference results in DRIFT (if connected via TGW)

[rgoltz]

Name of the resource

AWS::EC2::SecurityGroup

Resource Name

No response

Issue Description

• There are two options can be used to make a cross-account security group be able to be referenced in an inbound rule - https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html#security-group-referencing (TGW or VPC peering)

• If you are using Transit Gateway (TGW) and you reference a SecurityGroupId from the other account, we will already see a drift reported in CloudFormation for property SourceSecurityGroupOwnerId. Note: If you are using VPC peering in your connection setup it's not.

Expected Behavior

There is no drift reported, once I have security group ingress rules which reference a separate security group in another account.

Observed Behavior

The property SourceSecurityGroupOwnerId is reported as "Expected" in the drift details (in the account, where you have the stack, which reference the Security Group Id of the other account). Details see also "Test Cases" here in the issue.

If you are diving deeping into the underlying involved components, you will see the following: When performing a DescribeSecurityGroups API call on the security group created by the stack that is showing as drifted, the response does not include the UserId property. This corresponds to the SourceSecurityGroupOwnerId property in the stack. This can also be seen when viewing the security group in the EC2 console as well. The issue is that when although the API calls to actually put the security group rule are correctly specifying the UserId property to include the account of the referenced security group, the calls to describe the security group which are made during drift detection do not return this property for a TGW setup between VPCs. Then, on the CFN side it is marking this as drifted as a result.

So from this there are two elements in play. The first is that due to the presence of the SourceSecurityGroupId property, CFN is incorrectly expecting that SourceSecurityGroupOwnerId be set. Then, since the EC2 API is not returning this value, it also cannot be updated in the stack to resolve that drift.

Test Cases

prerequisite:

• Your need two different AWS accounts to repo this issue - important: the VPCs in these two accounts must be attached using a Transit Gateway (TGW)

steps:

• In account A (let's assume account-Id is 111111111111), please create a Security Group and note the Id somewhere (e.g. sg-1a2w3s4d5r6i7f8t9)

• Please go to other account B (account-Id is 222222222222 - both are connected via TGW) and create a stack like this blow - In a nutshell, create a AWS::EC2::SecurityGroup resource with a SecurityGroupIngress with the SourceSecurityGroupId of the other connected account:

AWSTemplateFormatVersion: 2010-09-09
Parameters:
  VpcId:
    Type: String
    Description: 'Enter the VPC ID where the Security Groups will be created e.g. vpc-0...'
Resources:
  SgRefToOtherAccountViaTgw:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: rogo-makeDriftDetectionGreatAgain-2310
      GroupName: rogo-makeDriftDetectionGreatAgain-2310
      VpcId: !Ref VpcId
      SecurityGroupEgress:
        - CidrIp: 0.0.0.0/0
          Description: allow all outbound traffic by default
          IpProtocol: "-1"
      SecurityGroupIngress:
        - Description: allow inbound via SecGroupId from OTHER account - the SecGroupId is from an other account.
          SourceSecurityGroupId: sg-1a2w3s4d5r6i7f8t9
          FromPort: 443
          ToPort: 443
          IpProtocol: tcp
      Tags:
        - Key: GithubIssueId
          Value: 2310
        - Key: AwsCaseId
          Value: 174060519500258

• Run a drift detection of this stack in check the drift details. You will see a drift for SourceSecurityGroupOwnerId - Please see screenshot below:

Other Details

No response