I ran in to a weird issue with aws.ec2.SecurityGro...
# aws
p
I ran in to a weird issue with aws.ec2.SecurityGroupRule, where one of a pair of rules did not seem to be created. I'll happily explain it all in detail if anyone wants me to, but then I read the docs page https://www.pulumi.com/registry/packages/aws/api-docs/ec2/securitygrouprule/ specifically the bit:
Copy code
NOTE on Security Groups and Security Group Rules: This provider currently provides a Security Group resource with ingress and egress rules defined in-line and a Security Group Rule resource which manages one or more ingress or egress rules. Both of these resource were added before AWS assigned a security group rule unique ID, and they do not work well in all scenarios using thedescription and tags attributes, which rely on the unique ID. The aws_vpc_security_group_egress_rule and aws_vpc_security_group_ingress_rule resources have been added to address these limitations and should be used for all new security group rules. You should not use the aws_vpc_security_group_egress_rule and aws_vpc_security_group_ingress_rule resources in conjunction with an aws.ec2.SecurityGroup resource with in-line rules or with aws.ec2.SecurityGroupRule resources defined for the same Security Group, as rule conflicts may occur and rules will be overwritten.
Which made some sense as to why I was having issues. But I can't find any docs for the aws_vpc_security_group_ingress_rule resource. How do I go about making one of those? and of course a matching aws_vpc_security_group_egress_rule?
s
I have some examples in Go, would that help?
Here’s some Go code I used to insert a security group rule into a security group created in another stack:
Copy code
_, err = ec2.NewSecurityGroupRule(ctx, "src-peer-cidr", &ec2.SecurityGroupRuleArgs{
	Type:            pulumi.String("ingress"),
	FromPort:        <http://pulumi.Int|pulumi.Int>(0),
	ToPort:          <http://pulumi.Int|pulumi.Int>(65535),
	Protocol:        pulumi.String("all"),
	CidrBlocks:      pulumi.StringArray{pulumi.String(netAddrMap[dstVpcRegion])},
	SecurityGroupId: srcNodeSecGrpId,
})
p
That's kinda helpful, it looks much like the TS I use to do it. But I ran into an issue where it seemed like the stack only managed to create one of a pair of security group rules. My code made a sg with egress rules for https and dns inline and then added two blocks like the above which took an existing sg from config and added an egress rule to it and an ingress rule to the one we made earlier to allow access to redis. When I ran the code I got the egress rule in the existing sg but the ingress rule in the sg we just made did not get created. I assume this is the kind of behaviour that note is warning about, but I don't see an other way to do it.
s
I think your assumption (this is behavior the note is warning about) is correct. When you say “an existing SG from config”, are you meaning an SG created by a different Pulumi program? Or an SG partly managed outside of Pulumi, and this Pulumi program is just plumbing additional ingress/egress rules? If the former, then I’d modify the other Pulumi program to define all rules separately (not inline). If the latter, then I’d consider whether I can use multiple SGs instead of modifying an SG that is partly managed outside Pulumi. (I understand this may not be possible.)
p
The existing sg from config, is a hand created (in the AWS UI) one. I'm in the process of migrating my infra into pulumi and the running services are in existing sg. I guess I could have potentially migrated everything at once, and thus not need to consider adding rules to an existing sg, but not now as I'm half way through the import/migration. What I will be doing is creating the new sg and sg rules with one operation and then importing and migrating the service over to it, so I can check that all the rules have been made and if not make them by hand.
Ah... I found my bug. I had sourceSecurityGroupId: and securityGroupId: round the wrong way in one of my blocks which meant the rules were both being made in the 1 sg. So pretty much ignore this thread
s
LOL! Glad you found the problem. 🙂