Feature request: array of secretNames in values.yaml

[EarthlingDavey]

Firstly, thanks for the very helpful tool. I have started using it in production, literally 2 minutes ago 😎

This feature would allow users to have multiple issuers, each with its own account on Hertzner with individual DNS API keys.

Would you mind considering this for the next release? My hacky work around at the moment is to manually create a role and role binding like this...

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cert-manager-webhook-hetzner:secret-reader-alt
  namespace: cert-manager
rules:
  - verbs:
      - get
      - watch
    apiGroups:
      - ""
    resources:
      - secrets
    resourceNames:
      - hetzner-secret-alt
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cert-manager-webhook-hetzner:secret-reader-alt
  namespace: cert-manager
subjects:
  - kind: ServiceAccount
    name: cert-manager-webhook-hetzner
    namespace: cert-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cert-manager-webhook-hetzner:secret-reader-alt

[vadimkim]

Sorry for the late reply. My notification settings for this repository were filtering the activity if my name was not directly mentioned. A bit strange.
Did you think about possible security issues of combining multiple individual API keys into one secret? As I understood there is one secret for all individual accounts, right?

[EarthlingDavey]

@vadimkim no worries for the late reply. I'll describe my use case to help explain.

I have ingress on cluster A:

• develop.myco.net
• staging.myco.net

Then on cluster B (production only).

• prod.myco.net <-- unpublished url for admin stuff like grafana
• myco.com <-- just for the customer facing website

If cluster A was to be compromised, I do not want the DNS for myco.com to be vulnreable. So, for that reason, my uncle created a new account with hetzner just to manage the DNS of myco.com.

This is why I have 2 hetzner DNS secrets on cluster B. I don't think this is a great security issue. What do you think?

[ibotty]

Any updates on how to manage two zones with different Hetzner accounts?

[vadimkim]

@ibotty, @EarthlingDavey I didn't fully understand the idea. Initially you talked about multiple secrets then about multiple zones. Container, if compromised, can reveal API token that can be used by attacker to change DNS records at Hetzner. This is problem, indeed. Very serious.
Multiple zones, as I understood, means that part of your domain (main site) is not managed by API token. And you don't store API token in Kubernetes. The part that is not faced to the customer (develop, staging) is managed by webhook. Thus, if API token is compromised you basically loose nothing (customer will not detect it). Impact is small.
Multiple secrets is less obvious. If container or platform has vulnerabilities than probably both secrets can be compromised. Having 2 of them is not more secure than having just 1. Or I didn't get the idea.
It is probably better to have long TTL for the A records and monitor DNS changes by another API working separately. Then you have time to react on attack and remove compromised tokens as well as recover records while they are still in the cache.

To improve security I am planning to upgrade base docker images first. Then we can think about DNS security as whole. Your solution looks complicated and benefits are not that obvious.

[ibotty]

Hi @vadimkim, thanks for taking care of it again! Very appreciated.

My use case is a multi-tenant(-ish) cluster that has dns zones managed by different hetzner accounts. ATM, I am using two clusterissuers but that way the right one always has to be specified.

If there were two secrets corresponding to these two accounts it would need chosing the issuer superfluous.

[EarthlingDavey]

Hey @vadimkim thanks for your reply. I think maybe I can add to my explanation to clear one thing up.

You say...

Having 2 of them is not more secure than having just 1.

.. this is correct in some scenarios, but not for my case.

Say I have myco .net <-- for staging and development on Cluster A.
I also want to re-use the .net domain for private stuff on Cluster B.

With that being the case I use the same Hetzner DNS account because clusters both use the .net domain.

So, what is the next logical step if I want to run only one public facing .com service on my production Cluster B?

Maybe I'm wrong, there could be a better way, but this is what I did...

Use a new Hetzner account with a 2nd API key to manage .com DNS.

Why did I decide to do this? Because, if Cluster A somehow leaks the secret for .net DNS, I have damage limitation and the attacker cannot modify my very important .com DNS records.

You are right though, if Cluster B is compromised then both secrets are leaked.

---

It sounds like a similar setup to @ibotty , but with a different reasoning.

It is probably better to have long TTL for the A records and monitor DNS changes by another API working separately. Then you have time to react on attack and remove compromised tokens as well as recover records while they are still in the cache.

This seems like solid advice, thank you!

To improve security I am planning to upgrade base docker images first.

Awesome, cheers!

I hope this reply comes across in the friendly manner that I intend, I appreciate your time and discussion 👊✌️