Certificates v1beta1 will no longer be support on k8s release 1.22

[Eoghan1232]

K8s release 1.22 onwards, it looks like k8s.io/api/certificates/v1beta1 will not be supported.
NRI will have issues once this happens.

Should we begin upgrading from v1beta1 to v1 for the certificates?

Recently, admission was switched from v1beta1 to v1.
https://github.com/k8snetworkplumbingwg/network-resources-injector/pull/96/files

[VivekThrivikraman-est]

From API version certificates.k8s.io/v1 onwards signerName is a required key for CSR's(certificate signing requests) and also they have made multiple built in signers for specific purposes which are supposed to be used for only k8s internal services.
Below are the few options which can be considered :

1. Use k8s internal kubelet-serving signer to sign nri webhook certificate, by making changes to the certificate request as required by that signer(like common name start with system:node etc).
2. Use custom signers like cert-manager(https://cert-manager.io/).
3. Use self signed certificate.

But all the above options have some disadvantages Option1: we would be using signer of kubelet Option2:Cert manager's support for k8s csr API is currently experimental and also this would add an additional dependency Option3:Is not normally used in production(but since it's all in cluster should this be ok?).

[adrianchiris]

some more info on the deprecation:

https://kubernetes.io/docs/reference/using-api/deprecation-guide/#certificatesigningrequest-v122

https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/#api-changes

info on K8s CSR and Signers:

https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#signers

Additional info on webhook tls cert:

https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/#tls-certificates

Naive question, in V1Beta who would issue the certificate ? (as signer name was not provided)

network-resources-injector/pkg/installer/installer.go

Line 101 in b1714b3

/* wait for the cert to be issued */

[adrianchiris]

Summary from today's discussion about this issue

Today, NRI supports either providing a signed certificate from an external source using tls-cert-file, tls-private-key-file
or by generating a certificate request and signing it using k8s signer via k8s certificates/v1beta1 API CertificateSigningRequest object (self approved by NRI).

The latter is no longer available in Kubernetes 1.22.
in k8s certificates/v1 a signer need to be provided.

see: https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/#api-changes

Kubernetes provides built-in signers however it seems that none of them fit the bill.

Specifically the only candidate to be used as a signer is kubernetes.io/kubelet-serving however it seems its only used to sign certificates intended to be used for kubelet serving endpoints that belong to system:nodes organization. This is not really what we need.

It is desirable to still have a way to generate a signed certificate without the need to create, sign and manage it out of band.

The proposal is to create a self signed certificate and use it in MutatingWebhookConfiguration instead of current mechanism.
Since requests are only served from within the cluster (no request from external network) this seems like a good path forward.

later on, if there is a use-case for it, we can revisit support for certificates/v1 CertificateSigningRequest with a custom signer.
e.g using cert-manager CertificateSigningRequest which is experimental at this point.

If we move forward with this proposal, I suggest the old code which uses certificates/v1beta1 to be removed and self signed certificates to be used instead.

@zshi-redhat do you see issues with this proposal ?
for downstream I assume you are using externally managed certificates.

IMHO this is a good path forward to have a good "out of the box" experience of NRI.

[zshi-redhat]

@zshi-redhat do you see issues with this proposal ?

This proposal sounds good to me, I don't see issues.

for downstream I assume you are using externally managed certificates.

We use a dedicated operator to manage the certificate signing activities downstream: https://github.com/openshift/service-ca-operator.

IMHO this is a good path forward to have a good "out of the box" experience of NRI.

Agreed