corymhall
commented
6 days ago @ixti thanks for creating this issue! After looking into this I think you may be running up against some default behavior of CloudFormation/CCAPI (which aws-native uses under the hood). By default when you create a security group via API a default egress-all rule will be created for you. For aws-native the only way to prevent that from happening is to provide a different rule instead. As long as one rule is provided, the default egress-all rule will not be created.
Also, the securityGroupEgress property on the SecurityGroup resource does not work well with the separate SecurityGroupEgress resource. Using both together can lead to unexpected rule deletion.
Below is an example of using securityGroupEgress with a dummy rule (doesn't allow any traffic, but prevents the egress-alll rule from being created) along with ignoreChanges. The ignoreChanges is necessary in order to work with the SecurityGroupEgress resource.
const albSecurityGroup = new awsNative.ec2.SecurityGroup(
'alb-sg',
{
groupDescription: 'Managed by Pulumi',
groupName: 'alb-sg',
vpcId: vpc.id,
securityGroupEgress: [
{
cidrIp: '255.255.255.255/32',
ipProtocol: 'icmp',
fromPort: 252,
toPort: 86,
description: 'Disallow all traffic',
},
],
},
{
provider: provider,
ignoreChanges: ['securityGroupEgress', 'securityGroupIngress'],
},
);
We should definitely document this, so I'll leave this issue open to track that progress.
ixti
What happened?
Results are unpredictable, and may break the configuration with each run.
After running Pulumi application it may create some security group rules, may create some that are not even defined (egress to any IPv4), or delete some that were previously created - while thinking those resources are still in place.
Example
Output of
pulumi aboutAdditional 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).