This message was deleted.
s
sparse-intern-71089
07/28/2023, 7:57 PMThis message was deleted.
s
salmon-account-74572
07/28/2023, 8:30 PMI have some examples in Go, would that help?
salmon-account-74572
07/28/2023, 8:34 PMHere’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
polite-napkin-90098
07/31/2023, 2:42 PMThat'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
salmon-account-74572
07/31/2023, 2:46 PMI 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
polite-napkin-90098
07/31/2023, 6:53 PMThe 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.
polite-napkin-90098
08/01/2023, 3:46 PMAh... 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
salmon-account-74572
08/01/2023, 3:48 PMLOL! Glad you found the problem. 🙂
9 Views
Pulumi Community
No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.
Powered by