Instead of giving cert-manager broad control of CloudFlare DNS, allow for a restricted token to be used. I found myself having to change apiKeySecretRef to apiTokenSecretRef and that allowed the cert to be issued correctly.
Current Behaviour
By changing from a global apiKey to a configurable apiToken, it would allow users better control and risk management. If the apiKey were to be exposed then it's possible for more damage to be done than a revocable and configurable apiToken.
Possible Solution
I would recommended making this an option in the init.yml to use an apiToken instead of an apiKey. So under tls_config for CloudFlare it would have an added option "use_token: false", false being default to prevent breaking actively deployed/rebuilding systems. Then in templates/k8s/tls/issuer-*.yml adding extra if statement that would flip "apiKeySecretRef" to "apiTokenSecretRef" if use_token was true.
Context
I wished to create a restricted CloudFlare API Token so that ofc would only have access to one domain. I did not feel comfortable risking all of my domains if I messed up the security of the Kubernetes cluster.
I personally am good with my manual fix but I am not happy to say it took me a few hours to troubleshoot this, so I wish to prevent others from having the same headache.
Your Environment
DigitalOcean DOKS with 3 (2 vCPU, 4GiB RAM) nodes.
CloudFlare DNS for tls issuing (because DigitalOcean doesn't provide dnssec).
Created a CloudFlare API Token from the template (Edit Zone DNS) and adding a Zone/Zone/Read to permissions in addition to the existing Zone/DNS/Edit that the template provided. I then restricted the Zone Resources to just one domain.
Expected Behaviour
Instead of giving cert-manager broad control of CloudFlare DNS, allow for a restricted token to be used. I found myself having to change apiKeySecretRef to apiTokenSecretRef and that allowed the cert to be issued correctly.
Current Behaviour
By changing from a global apiKey to a configurable apiToken, it would allow users better control and risk management. If the apiKey were to be exposed then it's possible for more damage to be done than a revocable and configurable apiToken.
Possible Solution
I would recommended making this an option in the init.yml to use an apiToken instead of an apiKey. So under tls_config for CloudFlare it would have an added option "use_token: false", false being default to prevent breaking actively deployed/rebuilding systems. Then in templates/k8s/tls/issuer-*.yml adding extra if statement that would flip "apiKeySecretRef" to "apiTokenSecretRef" if use_token was true.
Context
I wished to create a restricted CloudFlare API Token so that ofc would only have access to one domain. I did not feel comfortable risking all of my domains if I messed up the security of the Kubernetes cluster. I personally am good with my manual fix but I am not happy to say it took me a few hours to troubleshoot this, so I wish to prevent others from having the same headache.
Your Environment
DigitalOcean DOKS with 3 (2 vCPU, 4GiB RAM) nodes. CloudFlare DNS for tls issuing (because DigitalOcean doesn't provide dnssec). Created a CloudFlare API Token from the template (Edit Zone DNS) and adding a Zone/Zone/Read to permissions in addition to the existing Zone/DNS/Edit that the template provided. I then restricted the Zone Resources to just one domain.