Request for new repo: kubernetes/webhookauth

[benjaminapetersen]

New repo, staging repo, or migrate existing

new staging

Is it a staging repo?

yes

Requested name for new repository

webhookauth

Which Organization should it reside

kubernetes

Who should have admin access?

No response

Who should have write access?

No response

Who should be listed as approvers in OWNERS?

No response

Who should be listed in SECURITY_CONTACTS?

No response

What should the repo description be?
Kubernetes Webhook Auth implementation - https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/3299-kms-v2-improvements/README.md

(KEP link will be replaced with a documentation link once the docs exist)

What SIG and subproject does this fall under?
sig-auth

Please provide references to appropriate approval for this new repo
Pending approval:

Additional context for request
No response

[benjaminapetersen]

Related to kubernetes/kubernetes#140665

[liggitt]

webhook auth seems a touch narrow ... I suspect there are additional things commonly done by webhooks in the process of handling admission reviews that I could imagine us wanting to stick somewhere.

I could imagine either a sample-admission-webhook repo (like our existing sample-... repos) intended as a starting point (but not a library), or a repo like admission-webhook that has a package for authentication but allows for non-auth packages and helpers as well.

[enj]

a repo like admission-webhook that has a package for authentication but allows for non-auth packages and helpers as well.

Would we be okay with that package having its own go.mod file so controller-runtime can import just that package (they already have their own admission webhook logic)?

[liggitt]

eh... I'd like to avoid multi-module repos if possible for our staging stuff ... tagging with those is a huge pain. I'd expect deps like k8s.io/{api,apimachinery,client-go} and stdlib http deps, etc

[enj]

eh... I'd like to avoid multi-module repos if possible for our staging stuff ... tagging with those is a huge pain. I'd expect deps like k8s.io/{api,apimachinery,client-go} and stdlib http deps, etc

I suppose those deps are likely already used by controller-runtime so multi-module is probably unnecessary.

I would prefer an admission-webhook library repo over an example repo. I don't want to tell people to copy paste auth logic 🫠

[pmengelbert]

I am responding to two questions here, one from @dims and the other @aojea

@dims

can you please point me to how exactly someone outside k/k would use this new repo? (Do they have to so something new or it's all just baked in/enabled by default)

"Someone outside k/k", in this case, would be maintainers of admission webhooks. The repo will be imported so that webhook maintainers can verify the identity of the API Server (whether it is kube-apiserver or an aggregated API server) on incoming admission review requests. It implements the logic of verifying the signature via OIDC discovery (we avoid TokenReview), checking the audience, and verifying that kube-apiserver has attested to the resource group containing the resource about which the AdmissionReview request is being made.

Dependency chain might look something like this:

client-go and api-machinery -> kubernetes/webhook-auth -> controller-runtime -> gatekeeper
client-go and api-machinery -> kubernetes/webhook-auth -> kube-rbac-proxy

From @aojea:

Depending on your long-term goals for this library, you should consider the following:

• If the goal is to offer a stable, easily consumable library: It would be much better to handle this out-of-tree (e.g., as a standalone repository). This allows the library to maintain its own independent release cadence, semantic versioning, and stability guarantees without being bound to the Kubernetes core release cycle.

• If the goal is to offer a tightly coupled wrapper: Staging could make sense, but only if end-users are fully prepared to deal with breaking changes and the necessity of bumping their versions in lockstep with Kubernetes core releases.

The webhook token verification library should remain in lockstep with token issuance in kube-apiserver. We will never make a change to one without updating the other. It's hard to imagine a bug that affects one side and not the other; the components are tightly coupled by design. We want an integration test in k/k certifying that any changes to the issuer does not break the consumer. This keeps the two in sync and allows us to ensure that both issuer and consumer of these tokens remain backward-compatible indefinitely.

[enj]

kubernetes/kubernetes#140665 is the WIP PR for v1.38 that implements the logic for this issue.