REQUEST: Archive repo kubernetes-sigs/externalip-webhook

[aojea]

Repository to archive

kubernetes-sigs/externalip-webhook

Repository and/or sig subproject owners that are approving this archival

sig-network

When should this be done

Not urgent, as soon as github admins have time

Additional context for request

Reference slack thread https://kubernetes.slack.com/archives/C09QYUH5W/p1745244810058899

Quoting

can we archive https://github.com/kubernetes-sigs/externalip-webhook ? to address kubernetes/kubernetes#97076 we now have both VAP and kubernetes/kubernetes#97395 so I think it would be safe to go ahead and archive that repo since we don't seem to updating it?

The same functionality can be provided using VAP or the admission controller DenyServiceExternalIPs https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#denyserviceexternalips

[aojea]

/assign @danwinship @thockin
/cc @enj

[enj]

+1 from me

cc @kubernetes/security-response-committee

[danwinship]

The built-in admission controller only allows blocking all externalIPs, while the externalip-webhook lets you configure an allowed range (to solve the "stealing traffic to random IPs" bug) or allowed users (to solve the "untrusted users stealing other users' externalIPs" bug).

I'm pretty sure you can do both of those with a VAP, but maybe we should explain how explicitly?

(Or maybe not. 🤷‍♂ )

[danwinship]

we should at least update the repo's README before archiving it, right?

[aojea]

I think that is part of the process https://github.com/kubernetes/community/blob/master/github-management/org-owners-guide.md#removing-repositories

[palnabarun]

JFYI, As part of the archival process, the description is updated and not the README.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[danwinship]

I'm pretty sure you can do both of those with a VAP, but maybe we should explain how explicitly?

filed kubernetes/website#51689

[thockin]

LGTM