🌱 Add support for PKCS8 private keys in CA certs

[maelk]

What this PR does / why we need it:

This PR adds support for PKCS8 formatted CA private key, to prevent failure when a user provides his own CA key using the commands from the CAPI book : https://cluster-api.sigs.k8s.io/tasks/certs/using-custom-certificates.html
A setup with those commands would otherwise fail.

Which issue(s) this PR fixes :
Fixes #3173

[k8s-ci-robot]

Hi @maelk. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[maelk]

/assign @detiber

[fabriziopandini]

/ok-to-test

[benmoss]

/approve cancel

not enough coffee this morning

[maelk]

@detiber and @benmoss How do you propose to proceed with this change ? Should I change the APIs, and in that case, how do we ensure that go-apidiff would pass ? or should I try to keep the signature exactly the same for the existing functions ?

The failures were here : https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_cluster-api/3175/pull-cluster-api-apidiff/1271334352977924096

[benmoss]

go-apidiff isn't a merge-blocking job. I'll defer to @detiber for when we ignore it though, as I still don't entirely understand when it's okay 😄

[benmoss]

OK, I think I finally grok why you added the extra functions. I think @detiber is correct, that if you change all the *rsa.PrivateKeys to crypto.PrivateKeys, the signatures will remain valid for all the current use-cases, since that interface is a superset. That will still make the apidiff job fail, but we can ignore it I believe.

Maybe we want to use crypto.Signer actually instead since it is what x509.CreateCertificate depends on.

[benmoss]

Looks like another flake I added to my issue here #3197

/retest

[detiber]

This is looking really good, minor nit around the error being returned when all parsing attempts fail.

[detiber]

/lgtm
/assign @vincepri

[fabriziopandini]

@maelk thanks!
/lgtm

[fabriziopandini]

WRT to api-diff failures, rif #3175 (comment)

[benmoss]

@detiber y'approve?

[detiber]

Couple of minor nits related to gomega matchers being used for the tests, otherwise I think this is ready to go.

@maelk thank you for tackling this and working through the implementation with us :)

[vincepri]

/milestone v0.3.7

[k8s-ci-robot]

@maelk: The following test failed, say /retest to rerun all failed tests:

Test name	Commit	Details	Rerun command
pull-cluster-api-apidiff	77c424e	link	/test pull-cluster-api-apidiff

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[benmoss]

/lgtm
🎉

[benmoss]

/approve

[detiber]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: benmoss, detiber

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [detiber]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment