orphans: unassociated EIPs are reported unconditionally (no spawn/principal attribution), and both remediation hints are wrong — one is destructive

[scttfrdmn]

Summary

spawn orphans reports unassociated Elastic IPs with no ownership test at all, then tells the operator to remove them via two different mechanisms, both of which are wrong: one is a no-op, the other irreversibly deletes a resource spawn never created.

In a shared account this is an invitation to delete another project's static address. I hit it during a DFT pilot campaign in a multi-project account: the single EIP orphans reported and offered to clean up is the control-node address of an unrelated CloudFormation stack.

This is a follow-up to the EIP-visibility work in #262 / #273. #273 got the invariant exactly right — "spawn releases only what it alone creates … EIP handling here is therefore reporting-only" — and correctly hardened RemoveResource to refuse addresses. The gap is upstream of that: the scan that decides what to report has no attribution check for the unassociated case, and the user-facing text contradicts the invariant the code enforces.

Reproduction

spawn 0.100.0, commit 6521c239e5f246e4ddb476e5df67e4e58df241e5, build 2026-08-11T18:51:00Z, us-east-1.

$ spawn orphans --region us-east-1
REGION     SERVICE  TYPE     ID                          STATE         CREATED
us-east-1  ec2      address  eipalloc-002da3736d205bc22  unassociated  -

1 resource(s).

Run 'spawn cleanup' to remove these (running instances are never removed).

The reported address is not spawn's, is not mine, and carries no spawn:managed tag:

$ aws ec2 describe-addresses --allocation-ids eipalloc-002da3736d205bc22 \
    --region us-east-1 --query 'Addresses[0].{ip:PublicIp,tags:Tags}'
{
  "ip": "34.224.250.21",
  "tags": [
    {"Key": "elastic-gcs:role",                   "Value": "control"},
    {"Key": "elastic-gcs:region",                 "Value": "us-east-1"},
    {"Key": "Name",                               "Value": "elastic-gcs-control-us-east-1"},
    {"Key": "aws:cloudformation:logical-id",      "Value": "ControlNodeEIP"},
    {"Key": "aws:cloudformation:stack-name",      "Value": "ElasticGCS-Control-us-east-1"},
    {"Key": "aws:cloudformation:stack-id",        "Value": "arn:aws:cloudformation:...:stack/ElasticGCS-Control-us-east-1/..."}
  ]
}

It is a CloudFormation-managed ControlNodeEIP. Releasing it would break that stack and drift it, since CloudFormation still believes it owns the allocation.

Bug 1 — the "only yours" default does not apply to addresses

--all is documented as widening from "only yours" to "every principal in the account". For this address the two outputs are byte-identical:

$ spawn orphans --region us-east-1        # default: "only yours"
us-east-1  ec2      address  eipalloc-002da3736d205bc22  unassociated  -
$ spawn orphans --region us-east-1 --all  # "every principal"
us-east-1  ec2      address  eipalloc-002da3736d205bc22  unassociated  -

So the address row is unconditional. That is understandable — an EIP allocation has no creator attribution to filter on — but it means the narrowest invocation of orphans still reports a resource belonging to an unrelated stack, with nothing in the output to indicate that.

Note the asymmetry with #273's own reasoning. For an attached EIP, the association with a spawn instance is real ownership evidence, and #273's logic is sound. For an unassociated EIP there is no association left to test, so the same code path reports it with the ownership question silently unanswered.

spawn resources has the same issue, and is arguably worse: cleanup --help describes the resource set as "the shared AWS resources spore.host created (tagged spawn:managed)", but this untagged third-party address is listed in resources alongside genuinely spawn-managed instances and volumes.

Bug 2 — the orphans footer names a command that cannot act on addresses

The footer says:

Run 'spawn cleanup' to remove these (running instances are never removed).

Per #273 Part 2, cleanup filters addresses out by design. When the report contains only addresses — exactly my case — the footer's advice is a guaranteed no-op. An operator who follows it sees cleanup do nothing and reasonably concludes the tool is broken, or escalates to something that isn't a no-op.

Bug 3 — orphans --help asserts ownership the scan never established

spawn never allocates them, so it never releases them. Any EIP listed is yours to release with 'aws ec2 release-address'

The first clause is the correct invariant. The second does not follow from it: "spawn didn't create it" does not imply "you did." The help text converts an absence of attribution into a positive ownership claim, and then recommends the one AWS operation on an EIP that cannot be undone. This is the sentence that would have caused the damage — RemoveResource's refusal to release addresses is bypassed entirely, because the tool has routed the operator around its own guardrail and out to the raw CLI.

Impact

orphans is the safety net (#262: "at minimum, warn"). Here it warns about someone else's resource and hands over a destructive command with an unearned assurance of ownership. The failure is not that spawn deletes anything — #273 made sure it can't — it is that the text tells a human to do what the code correctly refuses to do.

Suggested fix

1. Attribute before reporting. For unassociated EIPs, treat presence of foreign ownership markers as disqualifying — at minimum aws:cloudformation:stack-id (and ideally any aws:* reserved-prefix tag, since those are written by AWS-managed provisioners, not by hand). Either drop them from orphans or move them to a clearly separate advisory section.
2. Show the evidence. Add a tag/owner column, or annotate the row (unassociated (CloudFormation: ElasticGCS-Control-us-east-1)). The operator needs the attribution in the report; requiring a manual describe-addresses to find out whether the safety net is pointing at a real problem defeats it.
3. Fix the footer conditionally. Do not print "Run 'spawn cleanup'" when the report contains no cleanup-eligible resources.
4. Rewrite the help sentence. Something like: "spawn never allocates Elastic IPs, so it never releases them. Any EIP listed here is outside spawn's control — verify its owner before acting, as release-address is irreversible." Drop the word "yours".

Point 4 is the one that matters most; 1–3 are defence in depth.

Workaround

Verified the tags manually and left the address alone. Recorded in the campaign's teardown log that the one resource spawn orphans reports is deliberately not mine and must not be released — a note that has to be re-made by hand on every teardown, because the tool asserts the opposite.

Related: #262 (EIP billing on stopped instances), #273 (added EIP visibility, established the reporting-only invariant).

[scttfrdmn]

Escalation on 0.100.2: spawn cleanup now prints the destructive command itself, with the IP filled in

Re-measured today on 0.100.2, commit 8086471e597f6957388c1cd3cd54bccd516dec05, build 2026-08-18T08:05:35Z, us-east-1, same account, same address. Two of this issue's three bugs have changed shape, and one of them changed for the worse.

Bug 3 has moved out of --help and into the output of a mutating command

orphans and resources were the surfaces in the original report; the ownership claim lived in orphans --help, where an operator has to go looking for it. It is now in spawn cleanup's own stderr, unprompted, with the allocation id and public IP interpolated into a ready-to-paste command:

$ spawn cleanup --dry-run --region us-east-1
REGION     SERVICE  TYPE      ID                          STATE         CREATED
us-east-1  ec2      address   eipalloc-002da3736d205bc22  unassociated  -
us-east-1  ec2      instance  i-03c73299d8b91b416         -             2026-08-17T22:39:51Z
[... 8 more rows ...]

10 resource(s).

ℹ️  1 Elastic IP(s) shown are user-owned — spawn never releases an EIP. If unneeded, release each yourself:
    aws ec2 release-address --allocation-id eipalloc-002da3736d205bc22   # 34.224.250.21 (us-east-1)

Dry run: 9 resource(s) would be removed. Re-run without --dry-run to delete.

That address is still ControlNodeEIP of the ElasticGCS-Control-us-east-1 CloudFormation stack, still untagged by spawn, still not mine. cmd/cleanup.go:100-103:

fmt.Fprintf(os.Stderr, "\nℹ️  %d Elastic IP(s) shown are user-owned — spawn never releases an EIP. If unneeded, release each yourself:\n", len(addresses))
for _, a := range addresses {
    fmt.Fprintf(os.Stderr, "    aws ec2 release-address --allocation-id %s   # %s (%s)\n", a.ID, a.PublicIP, a.Region)
}

"are user-owned" is the same unearned inference this issue's Bug 3 identified — "spawn didn't create it" does not imply "you did" — but stated as settled fact rather than as advice, in an ℹ️ block, at the moment the operator is already deciding what to delete. The interpolated command is the specific thing RemoveResource's address refusal exists to prevent. The guardrail is intact; the text routes around it and now does the typing.

The upstream cause is unchanged and is visible in pkg/aws/cleanup.go. scanAddresses's own doc comment states the invariant — "spawn never allocates an EIP, so every address here is a user-owned static address" — which is where the word "user-owned" comes from. The first clause is true; the second is the non-sequitur. classifyAddresses then decides purely on association state (instID == "" && assoc == "") with no tag inspection at all, so aws:cloudformation:stack-id never enters the decision.

Bug 2 is fixed, and that is what made Bug 3 worse

The original footer problem — orphans saying "Run spawn cleanup to remove these" when the report is addresses-only — is real but no longer the whole story: cleanup no longer no-ops silently on an addresses-only report. It hands over the raw CLI instead. Fixing the no-op by supplying the destructive command is the wrong direction from here; suggested fix #4 (drop the word "yours"/"user-owned", say verify the owner) is now the load-bearing one, and #1 (disqualify on aws:* reserved-prefix tags) would remove the row entirely.

Bug 1 is unchanged

Default and --all still agree on the address row. --all adds 14 IAM instance profiles and a security group; the address is present in both:

$ spawn orphans --region us-east-1        # "only yours"
us-east-1  ec2  address  eipalloc-002da3736d205bc22  unassociated  -
1 resource(s).

Attribution can't be filtered on spawn:iam-user for an EIP — DiscoverManagedResources's OnlyMine check compares that tag, and the address never went through buildTags, so it has no such tag to compare. The onlyMine filter is structurally inapplicable to the one resource class in the report that spawn didn't create.

Suggested wording

ℹ️  1 Elastic IP(s) are shown for visibility only — spawn never allocates or releases an
    EIP, so it cannot tell whether this one is yours. eipalloc-002da3736d205bc22
    (34.224.250.21, us-east-1) carries aws:cloudformation:stack-name=ElasticGCS-Control-us-east-1,
    which means another provisioner owns it. Verify the owner before acting;
    release-address is irreversible.

Printing the attribution spawn already fetched (DescribeAddresses returns the tags; classifyAddresses discards them) turns the row from a hazard into the safety net #262 asked for, with no new API calls.

Unrelated, found in the same output — filing separately

The nine non-address rows above are all gone: describe-instances returns {"Reservations": []} for each of the seven instance ids, and the two volumes 404. They are RGT tag-mapping residue, and "9 resource(s) would be removed" counts them. Separate mechanism, separate issue.