This message was deleted.

Hmmm maybe that's not the complete story. After the first refresh pulumi wants to remove the rule in the sg added by the eks module (I think) which is

"Allow pods to communicate with the cluster API Server"

which when removed will break the cluster.

Why are you refreshing? And, why is one SG being managed by two pieces of code?

I am refreshing to ensure that the infra and state match up, and every time I do so they appear to not match up

If you lock down your target account so that no one except Pulumi has update permissions, then you can skip the refresh step. Refreshing is good for recovering from accidental changes, but typically it is not needed. Refreshing exposes you to the risk of state change due to unimportant changes made by your cloud service. Things like unpredictable ordering (e.g. security group rules, WAF rules), default values and others, which do not affect the normal preview-up-repeat cycle, become potentially destructive and certainly inconvenient problems when you switch to a refresh-preview-up cycle. To get this working, you need to extend your dev work to include manually refreshing after each dev up then updating your code to match whatever the refresh changed. If refreshing pulls an unimportant default value from the cloud into your state, you need to update your code to match the state, or else Pulumi will try to delete that default value. And removing some default values can be a destructive action, causing a replace rather than an update.

So the solution was to let the EKS module create the sg, and then to add rules to it so I could access 443 from my AdminVM with code like

// add a rule allowing the AdminVM in to kubectl the cluster
const adminClusterRule = new aws.ec2.SecurityGroupRule("adminClusterRule", {
	type: "ingress",
	fromPort: 443,
	toPort: 443,
	protocol: "tcp",
	securityGroupId: clusterSecurityGroupId,
	sourceSecurityGroupId: adminsg.ids[0],
	description: `Allow AdminVM to communicate with the ${nam}-eksCluster API Server`,
});

If you try to create the sg first with a rule like that and then pass that to the

new eks.cluster

function as clusterSecurityGroup then you get into the state I describe.

I don't think it's a bug, unfortunately. It functions as designed. An alternative design that works better for IaC would be good: this design appears to have been created for console users.