OCPBUGS-44842: certrotation: set not-before/not-after annotations

[vrutkovs]

This ensures every secret managed by this controller has valid
not-before/not-after annotation set.
Instead of analyzing potentially sensitive secret
on customer cluster we should be able to tell if the certificate
rotation didn't happen and certificate expired by looking into
annotations.

Tested in openshift/cluster-kube-apiserver-operator#1768 and openshift/cluster-authentication-operator#742

[openshift-ci-robot]

@vrutkovs: This pull request references Jira Issue OCPBUGS-44842, which is invalid:

• expected the bug to target either version "4.18." or "openshift-4.18.", but it targets "4.19.0" instead

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

This ensures every secret managed by this controller has valid
annotation set. Instead of analyzing potentially sensitive secret
on customer cluster we should be able to tell if the certificate
rotation didn't happen and certificate expired by looking into
annotations

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 openshift-eng/jira-lifecycle-plugin repository.

[vrutkovs]

/jira refresh

[openshift-ci-robot]

@vrutkovs: This pull request references Jira Issue OCPBUGS-44842, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.19.0) matches configured target version for branch (4.19.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @wangke19

In response to this:

/jira refresh

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 openshift-eng/jira-lifecycle-plugin repository.

[vrutkovs]

/retest

[vrutkovs]

/retest

[openshift-ci]

@vrutkovs: all tests passed!

Full PR test history. Your PR dashboard.

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-sigs/prow repository. I understand the commands that are listed here.

[openshift-ci-robot]

@vrutkovs: This pull request references Jira Issue OCPBUGS-44842, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.19.0) matches configured target version for branch (4.19.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @wangke19

In response to this:

This ensures every secret managed by this controller has valid
not-before/not-after annotation set.
Instead of analyzing potentially sensitive secret
on customer cluster we should be able to tell if the certificate
rotation didn't happen and certificate expired by looking into
annotations.

Tested in openshift/cluster-kube-apiserver-operator#1768 and openshift/cluster-authentication-operator#742

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 openshift-eng/jira-lifecycle-plugin repository.

[vrutkovs]

/cherrypick release-4.18

[openshift-cherrypick-robot]

@vrutkovs: once the present PR merges, I will cherry-pick it on top of release-4.18 in a new PR and assign it to you.

In response to this:

/cherrypick release-4.18

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-sigs/prow repository.

[ibihim]

Technically, the wiring is fine, it makes sense to add NotBefore and NotAfter to EnsureTLSMetadataUpdate.

But the consequence is,

• that we need to invoke it twice and
• usually set the AdditionalAnnotations hand it down and execute it, while we could easily just set it in the given Secret.

To leverage EnsureTLSMetadataUpdate, we would need to split cert creation from injecting it into the Secret or create a more general EnsureSecretUpdate function that expects a TLS cert and then updates the metadata at once.

[vrutkovs]

that we need to invoke it twice

Yes, its unfortunate but see below

we could easily just set it in the given Secret.

It would require us to copy paste the code which does:

• make sure that annotations map is initialized (for newly created secrets)
• track annotation name (it may change in the future)
• this code can be reused in other components (e.g. ckoa PR uses AdditionalAnnotations to set not-before/not-after here as ApplySecret later already runs EnsureTLSMetadata)

[Elbehery]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Elbehery, vrutkovs
Once this PR has been reviewed and has the lgtm label, please assign jsafrane for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• pkg/operator/OWNERS

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

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[vrutkovs]

/remove-lifecycle stale