Skip to content

Conflicts between AWS CDK and Pulumi security group references?

0

Hi everyone!

I have a very specific doubt regarding creating new resources with AWS CDK while some of our existing infrastructure was originally created with Pulumi.

Context: Our VPC, load balancer, and security groups were created with Pulumi by the previous DevOps team. Now, our new team has started to migrate back to CDK to create and manage new resources (for example, new ECS Fargate services).

Here’s the situation:

In the past, I used to configure the Fargate service security group with an inbound rule of 0.0.0.0/0.

As part of new security requirements, I now need to restrict the inbound rule to only allow traffic from the load balancer security group instead.

So, I used this CDK code to create the service security group and reference the ALB’s security group:

security_group = ec2.SecurityGroup(
    self,
    f"{project_config.project_name}-{service_config.component}-{environment}-{service_config.country}-sg",
    vpc=vpc,
    description=f"Allow access traffic by {service_config.host_port} port",
    security_group_name=f"{project_config.project_name}-{service_config.component}-{environment}-{service_config.country}"
)

security_group.add_ingress_rule(
    ec2.Peer.security_group_id(service_config.security_groups_inbound),
    ec2.Port.tcp(service_config.host_port),
    "Ingress from ALB",
    remote_rule=False
)

The issue: When I deploy this stack with CDK, it creates the expected resources (service, task definition, etc.), but it also removes the outbound rule (0.0.0.0/0) that originally existed on the load balancer’s security group (which was created with Pulumi).

If the outbound rule is created manually, CDK does not touch it.

But if the outbound rule was managed by Pulumi, CDK seems to overwrite/remove it.

My question:

Do Pulumi- and CDK-managed resources conflict with each other in this way?

Is there a recommended approach to avoid CDK from modifying/deleting rules that were created with Pulumi?

Thanks in advance for any help or insights!

1 Answer
1
Accepted Answer

When you're working with security groups that were created by one IaC tool (Pulumi) and then referencing them in another tool (CDK), you can encounter conflicts in how the resources are managed.

The issue you're experiencing is related to how CDK handles security group rules when using add_ingress_rule with an existing security group. When you reference the Pulumi-created security group and set remote_rule=False, CDK is trying to modify the security group rules directly, which can conflict with Pulumi's state management.

To avoid CDK modifying or deleting rules that were created with Pulumi, you should import the existing security group as an immutable reference rather than trying to modify it. Here's how you can approach this:

  1. Import the existing security group using fromSecurityGroupId:
alb_security_group = ec2.SecurityGroup.from_security_group_id(
self, 
"ImportedALBSecurityGroup", 
service_config.security_groups_inbound,
mutable=False  # This is important - marks it as immutable
)
  1. Then use this imported security group reference in your ingress rule:
security_group.add_ingress_rule(
ec2.Peer.security_group_id(alb_security_group.security_group_id),
ec2.Port.tcp(service_config.host_port),
"Ingress from ALB"
)

Alternatively, if you need to maintain bidirectional rules between security groups, you might need to use CloudFormation exports/imports to reference the security group IDs. This approach involves:

  1. Exporting the security group ID from Pulumi
  2. Importing it in CDK using Fn.importValue
  3. Using SecurityGroup.fromSecurityGroupId to reference it

This way, CDK will only manage the rules for the security groups it creates, and won't attempt to modify the Pulumi-created security groups.

When working with mixed IaC tools, it's generally best to keep clear boundaries between what each tool manages to avoid conflicts.
Sources
class SecurityGroup (construct) · AWS CDK
CDK - Importing and modifying security group from a previous stack | AWS re:Post

answered a year ago

EXPERT

reviewed a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.