search

linkerd / linkerd2

Ultralight, security-first service mesh for Kubernetes. Main repo for Linkerd 2.x.
https://linkerd.io
Apache License 2.0
10.63k stars 1.28k forks source link

allowing issuer crt/key to have been pre-base64'ed #12848

Closed SamKirsch10 closed 2 months ago

SamKirsch10 commented 3 months ago

When having issuer certs as secrets elsewhere, they may already be base64 encoded. This will ensure things don't get double base64 encoded.

The identity template has been edited to allow a new .crtPEM64 and keyPEM64 values variable that can be supplied if these have already been base64 encoded.

Validated by ensuring yaml still templates correctly.

mateiidavid commented 2 months ago

Hey @SamKirsch10. If I understand it right, the main motivation is that you already have a secret that you'd like to use as the identity public & private keys. How do you plan on using this secret? Does it already exist in your Kubernetes cluster?

I'm thinking it might perhaps be a bit easier if instead of fetching the secret and then using it as a value for linkerd's install/upgrade you could simply replicate the secret in the linkerd namespace and have the control plane automatically pick it up?

Would be great to get a few more details in how you want to use the feature and what concrete problem it solves (that we otherwise wouldn't be able to solve with the existing configuration). It'd help us a lot in reviewing your change! :)

SamKirsch10 commented 2 months ago

Hey @mateiidavid - We keep any secrets (k8s, not k8s) encrypted via Google KMS. They're base64'd & encrypted. We use ArgoCD to deploy our helm charts, and have a layer in argo that can decrypt the secret in the values file and pass it to helm template in a decrypted, but base64'd format. This poses a problem for us since the identity secret in this chart automatically base64's the inputs in question.

I guess if we don't want additional variables in the values file, we can use a similar setup that is already in place for .Values.identity.externalCA, but for the linkerd-identity-issuer secret. That way we can deploy the secret ourselves? Is that a more friendly solution?

mateiidavid commented 2 months ago

@SamKirsch10 I see, thanks, that's really helpful! Have you had a look at our Automatically Rotating Certificates docs page? Linkerd can be installed without providing an identity issuer secret, provided one exists already. If I remember correctly, you just need to pass in --set identity.issuer.scheme=kubernetes.io/tls. This will tell Helm (or the CLI) to skip creating the secret.

Does this work for you?

SamKirsch10 commented 2 months ago

@mateiidavid - I guess that works fine. We already have cert-manager running! Thanks