Description of problem:

Cu using OpenShift 4.11.
Cu running Argo CD (v2.6.4) to manage most of the workload.
Cu also utilizing cert-utils-operator (v1.3.10)
Reproduction of the problem:
~~~
Add the following resource to an Argo CD application:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
cert-utils-operator.redhat-cop.io/certs-from-secret: "<secret-name>"
name: test-route
spec:
host: <hostname>
port:
targetPort: http
tls:
termination: edge
to:
kind: Service
name: test
~~~
where <secret-name> is a kubernetes tls secret, obviously not tracked by git, but provided by a secret management solution.

When the resource "test-route" is sychronized by Argo CD, cert-utils-operator will inject the field .spec.tls.certificate and .spec.tls.key into the resource.
Afterwards, the field .spec.tls.key is visible in the live manifest in the Argo CD web UI.
(See the attached image)

Workaround

Prerequisites (if any, like setup, operators/versions):

Steps to Reproduce

~~~
apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
cert-utils-operator.redhat-cop.io/certs-from-secret: "<secret-name>"
name: test-route
spec:
host: <hostname>
port:
targetPort: http
tls:
termination: edge
to:
kind: Service
name: test
~~~

 # <steps>
where <secret-name> is a kubernetes tls secret, obviously not tracked by git, but provided by a secret management solution.

When the resource "test-route" is sychronized by Argo CD, cert-utils-operator will inject the field .spec.tls.certificate and .spec.tls.key into the resource.
Afterwards, the field .spec.tls.key is visible in the live manifest in the Argo CD web UI.
(See the attached image)

In contrast to that, the sensitve fields in the actual secret resource are hidden in the Argo CD web UI.
Our expectation would be that the sensitive fields in the route object will be treated the same way as the ones in a secret.
Cu interested to know if there is a solution which will fulfill our expectations.

To address some of your questions:
cu do not have any customization in place which cause any change to the visibility of sensitives fields. Would that be even possible? If so, could you install a customization which would hide the field .spec.tls.key?
For the cert-util-operator, we employ the default configuration, and others also do not touch anything that would affect the problem.

 h3. Actual results:
Screenshift added

Expected results:

Screenshot added

Reproducibility (Always/Intermittent/Only Once):

updated

Acceptance criteria: 

NA
 

Definition of Done:

Build Details:

NA

Additional info (Such as Logs, Screenshots, etc):

Attached
 

 *