OIDC: Tolerate extra service-account key set items

[seh]

When reading the kOps "service-account" key set in preparation for publishing the OIDC JWKS file (such as to S3 alongside the discovery document), in some cases the set contains items that either lack an X.509 certificate or contain such a certificate issued for a subject with common name other than "service-account." Ignore these extra key set items and instead only project JWKS keys for those with an X.509
certificate with the expected subject common name.

Refs: #14174

[hakman]

/cc @olemarkus

[hakman]

/lgtm

[hakman]

/retest

[olemarkus]

This test looks sane, but I wonder if you can still end up in issues elsewhere. Especially if certificate rotation works.

I would assume that kops get keypairs still fails as well, so this wouldn't be a full fix of #14174.

[hakman]

This would at least unblock deployment and it can be iterated later.
Also, one could always distrust older keys.

[olemarkus]

Yeah. I just wanted to unlink the issue so it doesn't get closed.

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: olemarkus

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 [olemarkus]

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

[seh]

I would assume that kops get keypairs still fails as well, so this wouldn't be a full fix of #14174.

Yes, that's true. I didn't realize that kops get keypairs fails until after I had proposed this fix for the failure in kops update cluster, and I neglected to change the "Fixes" comment.

I expect that there are several more places that read key pairs that will need similar treatment.

[seh]

Please see #14370 for making kops get keypairs more tolerant as well.