use RotatedSigningCASecret and RotatedSelfSignedCertKeySecret only in update mode

[p0lyn0mial]

UseSecretUpdateOnly is intended as a short term hack for a very specific use case,
and it works in tandem with a particular carry patch applied to the openshift kube-apiserver.
(openshift/kubernetes#1924)

we will remove this when we migrate all of the affected secret
objects to their intended type: https://issues.redhat.com/browse/API-1800

the issue is that the secret's crypto material
can be regenerated, which has serious consequences for the platform
as it can break external clients and the cluster itself.

xref: openshift/library-go#1705
xref: openshift/kubernetes#1924

[openshift-ci-robot]

@p0lyn0mial: This pull request references Jira Issue OCPBUGS-31384, which is valid.

3 validation(s) were run on this bug

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

Requesting review from QA contact:
/cc @wangke19

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

In response to this:

UseSecretUpdateOnly is intended as a short term hack for a very specific use case,
and it works in tandem with a particular carry patch applied to the openshift kube-apiserver.
(openshift/kubernetes#1924)

we will remove this when we migrate all of the affected secret
objects to their intended type: https://issues.redhat.com/browse/API-1800

in short tls secrets used by this operator are reconciled
by multiple controllers (the cert controller run by the operator and the same controller run by the recovery pod) at the same time without any coordination.

the issue is that the secret's crypto material
can be regenerated, which has serious consequences for the platform
as it can break external clients and the cluster itself.

xref: openshift/library-go#1705
xref: openshift/kubernetes#1924

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.

[p0lyn0mial]

/hold

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: p0lyn0mial
Once this PR has been reviewed and has the lgtm label, please assign tjungblu for approval. For more information see the Kubernetes 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:

• OWNERS

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

[tjungblu]

@p0lyn0mial I think we don't need to have that flag set, none of the certs that you tag are created with the SecretTLS type AFAIK

[p0lyn0mial]

@p0lyn0mial I think we don't need to have that flag set, none of the certs that you tag are created with the SecretTLS type AFAIK

I'm still testing, so far we have at least

cluster-etcd-operator/manifests/0000_20_etcd-operator_03_secret.yaml

Line 3 in eeef803

type: SecretTypeTLS

[tjungblu]

That's for CEO, we can simply patch that out.

[openshift-ci]

@p0lyn0mial: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-agnostic-ovn-upgrade	ef6098b	link	true	/test e2e-agnostic-ovn-upgrade
ci/prow/e2e-gcp-qe-no-capabilities	ef6098b	link	false	/test e2e-gcp-qe-no-capabilities
ci/prow/e2e-aws-ovn-serial	ef6098b	link	true	/test e2e-aws-ovn-serial
ci/prow/e2e-operator-fips	ef6098b	link	true	/test e2e-operator-fips

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.

[p0lyn0mial]

That's for CEO, we can simply patch that out.

We should, we should also make sure that the secret created in the previous versions will be safely migrated to the new type.

@p0lyn0mial I think we don't need to have that flag set, none of the certs that you tag are created with the SecretTLS type AFAIK

Vadim created a 4.6 cluster and below is the list of secrets with the old type.
However, considering the platform's long history spanning several years, I am not convinced that the secrets could have been created using only one type

openshift/kubernetes#1929 (comment)

[tjungblu]

Great list, I think we might be OK still, given the clients can be updated safely. Let me know how your testing goes.

Keep in mind that most secrets outside of openshift-etcd will be simply copied through the resource controller.
Its implementation IIRC will also simply delete+recreate, so the patching in here might not be sufficient (if we really need it).

[openshift-ci-robot]

@p0lyn0mial: No Jira issue is referenced in the title of this pull request.
To reference a jira issue, add 'XYZ-NNN:' to the title of this pull request and request another refresh with /jira refresh.

In response to this:

UseSecretUpdateOnly is intended as a short term hack for a very specific use case,
and it works in tandem with a particular carry patch applied to the openshift kube-apiserver.
(openshift/kubernetes#1924)

we will remove this when we migrate all of the affected secret
objects to their intended type: https://issues.redhat.com/browse/API-1800

the issue is that the secret's crypto material
can be regenerated, which has serious consequences for the platform
as it can break external clients and the cluster itself.

xref: openshift/library-go#1705
xref: openshift/kubernetes#1924

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.

[p0lyn0mial]

/close

a fix (if any) will be delivered via https://issues.redhat.com/browse/API-1800

[openshift-ci]

@p0lyn0mial: Closed this PR.

In response to this:

/close

a fix (if any) will be delivered via https://issues.redhat.com/browse/API-1800

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.