Dynamically reference the identity trust anchor certificate

[Tolsto]

What problem are you trying to solve?

When installing linkerd via the Helm chart you have to supply the identity trust anchor certificate via the identityTrustAnchorsPEM chart value. Consider a setup that follows a gitops workflow and uses cert-manager for the intermediary CA and an external Issuer like Hashicorp Vault for the root CA. In such a scenario, the user has to copy the CA cert manually from Vault and paste it into the Helm values file which makes it impossible to set up a cluster in a single step without manual intervention.

How should the problem be solved?

The Secret for the intermediary CA already contains the root CA certificate. It would be great if Vault could get the root CA cert from there.

Any alternatives you've considered?

How would users interact with this feature?

No response

Would you like to work on this feature?

maybe

[olix0r]

1. We do not want to support a "dynamic" trust root. There are a number of operational/security issues with making it possible to change trust roots at runtime without restarting workloads. All proxies load the trust anchors at startup and require restart to change the roots.
2. It's an annoying limitation of cert-manager that it only publishes the root ca cert in a secret. We currently load the anchors from a configmap--we want them to be publicly readable by tools that don't (and shouldn't) have access to the secret. This includes the proxy injector and destination controllers, which should not have access to the issuer key.
3. https://github.com/cert-manager/trust may be able to publish the root to the configmap. I think someone has gotten that working in the past...

At the very least, we can probably support a mode where we do not create the trust anchors configmap so that control plane pods are not scheduled until the config map is created by something else.

the user has to copy the CA cert manually from Vault and paste it into the Helm values file which makes it impossible to set up a cluster in a single step without manual intervention.

can this not be automated? i.e. is it possible to obtain the roots from vault when configuring linkerd?

[Tolsto]

the user has to copy the CA cert manually from Vault and paste it into the Helm values file which makes it impossible to set up a cluster in a single step without manual intervention.

can this not be automated? i.e. is it possible to obtain the roots from vault when configuring linkerd?

When you have all manifest, including the Vault PKI, in a git repository and use it as your authoritative source of truth then that would require to have a system that gets the CA certificate from Vault and then push a commit to the manifest repository. That system would have to be able to detect when there is a mismatch between the configured certificate in the git repository and the CA in Vault as this would be the scenario that happens when you re-create the cluster from scratch. That sounds like a very complicated and, in the spirit of declarative gitops, wrong solution.

[Tolsto]

1. We do not want to support a "dynamic" trust root. There are a number of operational/security issues with making it possible to change trust roots at runtime without restarting workloads. All proxies load the trust anchors at startup and require restart to change the roots.

But isn't the same true when you rotate the root CA and change the certificate via the Helm chart? The only difference is that you have to manually replace the root certificate. However, that still means that you have to restart all workloads and you also run into problems if the root CA changes and you don't coordinate the change. I.e. you have to know that you must not rotate the root CA without coordinating the change with the linkerd installation.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.