OCPBUGS-24212: Add ownership annotation for certificates

[vrutkovs]

• I added CHANGELOG entry for this change.
• No user facing changes, so no entry in CHANGELOG was needed.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[vrutkovs]

/test e2e-aws-ovn

[vrutkovs]

/test e2e-aws-ovn

[vrutkovs]

/test e2e-aws-ovn

[vrutkovs]

/test e2e-aws-ovn

[vrutkovs]

/test e2e-aws-ovn

[vrutkovs]

/test e2e-aws-ovn

[vrutkovs]

/test e2e-aws-ovn

[vrutkovs]

/test e2e-aws-ovn

[raptorsun]

How these new annotation will be used?

[vrutkovs]

This would help customers file correct bug reports. This case is fairly obvious, but its not the case for other components. Also it can help us find situations when a team adds a new unregistered TLS artifact. More metadata would be added to these secrets later.

See openshift/enhancements#1502 for more information

[rexagod]

I see the changes introduced here are in-line with: "As an Openshift developer, I want to be able to find which team manages a particular certificate.". While this looks fine, we should hold off on merging this until the EP gets in.

[deads2k]

Ownership annotations are already in the openshif/api. The enhancement is about building an automatic report against those annotations, not the annotations themselves. IOW: the annotations are ready for merge now.

[jan--f]

We pre-generate static assets and I think the annotation can be added there already. See https://github.com/openshift/cluster-monitoring-operator/blob/master/jsonnet/utils/generate-certificate-injection.libsonnet. Adding the annotation there will probably do the trick. That'll keep things consistent for future ca-bundle ConfigMaps.
Is there a JIRA we can attach to this?

[openshift-ci-robot]

@vrutkovs: This pull request references Jira Issue OCPBUGS-24212, 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.15.0) matches configured target version for branch (4.15.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @juzhao

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

In response to this:

• I added CHANGELOG entry for this change.
• No user facing changes, so no entry in CHANGELOG was needed.

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.

[vrutkovs]

Adding the annotation there will probably do the trick

IIUC these will not be applied to the upgraded clusters? If these would work too I can create a follow up PR

[simonpasquier]

IIUC these will not be applied to the upgraded clusters?

They will/should be applied on upgrades.

[vrutkovs]

Ah, certs with inject-trusted-cabundle are not really owned by monitoring team - cluster-network-operator injects CA bundle there and it annotates them already.

Also, more cert-specific metadata would be added there (i.e. cert description) so we still need a place where its being set per-cert/configmap

[simonpasquier]

Adding the "openshift.io/owning-component" annotation in the jsonnet code is the right thing to do IMHO because the information is static and it's way easier for future ourselves.

IIUC we don't have to do anything for certificates which are issued by the service-ca operator and the cluster-network-operator?
AFAICT CMO manages directly only the gRPC TLS certificates for thanos-querier, prometheus-k8s, thanos-ruler and prometheus-user-workload (assets/*/grpc-tls-secret.yaml).

[vrutkovs]

@simonpasquier I don't mind adding the annotations to jsonnet code, but I can't seem to find where these are defined. Any pointers?

[raptorsun]

@simonpasquier I don't mind adding the annotations to jsonnet code, but I can't seem to find where these are defined. Any pointers?

The labels/annotations can be added here and it will be applied to all ca bundle config maps generated from this jsonnet function. Here is where the CA bundle is generate for alertmanager.

We put static informations in jsonnet files and dynamic informations in the controller code.

[jan--f]

You now just need to run make generate and commit the results.

[vrutkovs]

Done, now component annotation is set in jsonnet where possible

[raptorsun]

/test e2e-aws-ovn-techpreview

[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/test-infra repository. I understand the commands that are listed here.

[simonpasquier]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: simonpasquier, vrutkovs

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

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

[openshift-ci-robot]

@vrutkovs: Jira Issue OCPBUGS-24212: All pull requests linked via external trackers have merged:

• openshift/cluster-monitoring-operator#2158

Jira Issue OCPBUGS-24212 has been moved to the MODIFIED state.

In response to this:

• I added CHANGELOG entry for this change.
• No user facing changes, so no entry in CHANGELOG was needed.

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.

[openshift-merge-robot]

Fix included in accepted release 4.15.0-0.nightly-2023-12-08-080446