The same also applies to secrets of type tls, they are getting type "Opaque"...

Just noticed this, I've had the same issue with kubernetes.io/dockerconfigjson...
Workaround is to specify it in the mirror but then you have to specify a dummy value for dockerconfigjson which results in the reflected value being overwritten when the mirror manifest is applied.

Based on the lack of responses on this and my other issue, I'm starting to fear this project is abandoned.

@Findaa @mateuszdrab can you provide a sample of the source secret?

@Findaa @mateuszdrab can you provide a sample of the source secret?

I think any secret other than opaque will do. The issue is that you can't create an empty tls secret or an empty dockerjsonconfig secret so if you create an opaque one as a placeholder and add the necessary annotation to make reflector act on it, reflector will copy the data but won't be able to change the type of the secret as that is blocked by the api server. A workaround could be to have reflector recreate the secret instead with the right type.

The workaround from my previous comment is not a good one since solutions like flux will constantly reconcile the secret to the initial value removing whatever reflector put in - that is if you apply the secret with the right type and some empty data in the tls/dockerjsonconfig.

This shouldn't be a problem with auto-mirrors (copies created automatically) but it will be a problem with annotated reflections since validation will kick in.

This shouldn't be a problem with auto-mirrors (copies created automatically) but it will be a problem with annotated reflections since validation will kick in.

That is exactly the problem...

I can confirm the auto-mirrors work as expected for the type: kubernetes.io/tls

Here is a source secret with a pseudo TLS certificate (content of the keys is not relevant for the issue reproduction):

apiVersion: v1
kind: Secret
type: kubernetes.io/tls
metadata:
 name: test-tls-secret-source
 namespace: kong
 annotations:
 reflector.v1.k8s.emberstack.com/reflection-allowed: "true"
 reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "" # all namespaces
 reflector.v1.k8s.emberstack.com/reflection-auto-enabled: "true"
 reflector.v1.k8s.emberstack.com/reflection-auto-namespaces: "myapp1"
data:
 tls.crt: YWJjY3J0
 tls.key: YWJjMTIz

Here is corresponding mirror secret:

apiVersion: v1
kind: Secret
type: kubernetes.io/tls
metadata:
 name: test-tls-secret-mirror
 namespace: myapp1
 annotations:
 reflector.v1.k8s.emberstack.com/reflects: "kong/test-tls-secret-source"
data:

The source secret is successfully auto-mirrored into namespace myapp1, but deploying 'manual request' mirror secret fails:

$ kubectl apply -f tls-secret-mirror.yaml 
The Secret "test-tls-secret-mirror" is invalid: 
* data[tls.crt]: Required value
* data[tls.key]: Required value

At first I thought I'm supposed to include explicit keys with empty placeholders:

data:
 tls.crt:
 tls.key:

but this does not help - secret is created but it is not reflected really, values are empty in created secret resource.

AFAIS, this is not considered as a bug - label has been removed - this is not a convenient behaviour, not documented for sure.

Reflector cannot create or operate secrets that fail k8s type validations. The source secret HAS to be valid, otherwise mirrors will fail to be created (since they will not pass validation). Reflector copies the type and data when creating the mirror and submits to the API server, either resulting in a success and the mirror is created or a failure due to validation errors or collisions. These cannot be handled by the reflector logic.