generating the truststore in an new secret of type Opaque

[ocpvkb]

When creating a Secret, you can specify its type using the type field of a Secret resource, or certain equivalent kubectl command line flags (if available).
The type of a Secret is used to facilitate programmatic handling of different kinds of confidential data.
Kubernetes provides several builtin types for some common usage scenarios.
These types vary in terms of the validations performed and the constraints Kubernetes imposes on them.
Kubernetes provides a builtin Secret type kubernetes.io/tls for storing a certificate and its associated key that are typically used for TLS . This data is primarily used with TLS termination of the Ingress resource, but may be used with other resources or directly by a workload.
When using this type of Secret, the tls.key and the tls.crt key must be provided in the data (or stringData) field of the Secret configuration, although the API server doesn't actually validate the values for each key.
The TLS Secret type is provided for user's convenience. You can create an Opaque for credentials used for TLS server and/or client. However, using the builtin Secret type helps ensure the consistency of Secret format in your project; the API server does verify if the required keys are provided in a Secret configuration.

By injecting the kubernetes.io/tls secret type to hold a truststore you change the request for comments of the secret type.

e.g.

1. A kubernetes "certificate" controller/operator defines kubernetes.io/tls secret in a correct declariative way: PEM format, stored in tls.crt and tls.key.
2. When you annotate this secret to proceed by the cert-utils-operator the truststore is created.
3. Within the next reconciling loop of the kubernetes "certificate" controller/operator (from 1. ), the trustore is removed.
4. Within the next reconciling loop of the cert-utils-operator the truststore is created again.
   .....
   !! This ends in an endless loop !!
   This behavior is currently not intercepted.

Basically the modification, adding the truststore to a secret of type kubernetes.io/tls by the cert-utils-operator you move away from the standard....

Generating the truststore in an new Secret of type Opaque would be a better solution or at least the configuration option.

[ocpvkb]

/remove-lifecycle stale

[ocpvkb]

/remove-lifecycle stale

[ocpvkb]

/remove-lifecycle stale