search

Azure / AppConfiguration-KubernetesProvider

Bring your data in Azure App Configuration down to your Kubernetes cluster, available as ConfigMap and Secrets and ready to be consumed by any workload.
MIT License
5 stars 3 forks source link

TLS Key Vault references generating opaque not tls secrets #81

Open trhumphries opened 1 week ago

trhumphries commented 1 week ago

I have a reference to a certificate in a KV with the .kubernetes.secret.type set to kubernetes.io/tls. However instead of a tls secret it generates an opaque secret. This did work 2 days ago the latest 2.0.0 update seems to have broken it.

trhumphries commented 1 week ago

BTW, I just tried the 2.1.0 release and it also creates as an opaque secret

trhumphries commented 1 week ago

Not sure if this will help. If I change the target.secretName to point to a non-existant value in the App Configuration. It hone generates 2 secrets one called nonexistantsecret that is of type opaque and one with the name of the certificate from the KV that is of type tls

secret: auth: workloadIdentity: serviceAccountName: appconfigidentity target: secretName: nonexistantsecret

linglingye001 commented 5 days ago

Hi @trhumphries , this behavior is expected. The spec.secret and spec.secret.target are required if any Key Vault references are expected to be downloaded. By default, Secrets resolved from Key Vault references (without .kubernetes.secret.type specified) are saved as the Opaque Secret type with target.secretName.

RichardChen820 commented 5 days ago

The one that has got the .kubernetes.secret.type: kubernetes.io/tls tag is saved as tls type secret, since there's no other secret selected, an empty opaque secret is generated.