repoCA as a secret reference

[poblin-orange]

helm contoller enables setting corporate ca in pem format. However, is format is not really convenient (expects clear text pem, whereas this type cert is usually managed as base64 encoded secret data). Offering secretRef, or local fs would be helpfull.

[brandond]

this type cert is usually managed as base64 encoded secret data

When storing certs+keys for a kubernetes.io/tls type secret, yes. However, TLS secrets require both a cert and key, and it most cases it wouldn't be appropriate for a client (Helm in this case) to have access to the key. And if you don't need to store the key, then why are you using a secret to store the public certificate? Certificates are not confidential.

We may add this when we add support for a SecretRef for registry auth, but tbh I don't really see why you would want to keep a cert in a secret.

[poblin-orange]

Hi @brandond Agreed in that case we should use on Opaque type Secret. For instance, fluxcd Notification has this type of cross ref. https://fluxcd.io/flux/components/notification/provider/#example-1

My use case is the following:

• im deploying a k3s cluster in a edge environment, with kairos.io https://kairos.io/docs/advanced/build/
• to have it auto installed, im using k3s HelmChart, referencing a corporate helm repo.

The helm repo and caRepo need to be fed in the kairos cloud-config file. In that context, escaping multi-line ca cert is unpractical (see https://kairos.io/docs/advanced/build/#build-a-cloud-image) On the other hand, i could easily feed the caRepo with the single line base64 encoded value from my master cluster.

[brandond]

I still don't think a secret is the right place for it, if anything it should be in a separate configmap, similar to the kube-root-ca.crt configmap that is injected into namespaces. If it doesn't have a confidential component (no private key) it belongs in a configmap, not a secret.

I will also note that even in this case, the certificate is injected in PEM format:

root@k3s-server-1:/# kubectl get configmap kube-root-ca.crt -o yaml
apiVersion: v1
data:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    MIIBdzCCAR2gAwIBAgIBADAKBggqhkjOPQQDAjAjMSEwHwYDVQQDDBhrM3Mtc2Vy
    dmVyLWNhQDE2ODE4Mzk0MzYwHhcNMjMwNDE4MTczNzE2WhcNMzMwNDE1MTczNzE2
    WjAjMSEwHwYDVQQDDBhrM3Mtc2VydmVyLWNhQDE2ODE4Mzk0MzYwWTATBgcqhkjO
    PQIBBggqhkjOPQMBBwNCAARxvXycpETNDwPDybJGDWrWyK4bZJZwn0TwSSXnR6HZ
    F6fnXyHQEG3D/WntrBOYOve2Pk/GJTgnJwPSBBGTkQj2o0IwQDAOBgNVHQ8BAf8E
    BAMCAqQwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUXzzDMs835M/urfmuLf8/
    piMxE1UwCgYIKoZIzj0EAwIDSAAwRQIhAJZiZ2wEH0WQPBdwyWlhFbeAQLqbiBTI
    tNYRD805z8WYAiAxqwVEjAYp/0LsT6ZdD2NwwEYQbc9tUcI41M+jIDGu6g==
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  annotations:
    kubernetes.io/description: Contains a CA bundle that can be used to verify the
      kube-apiserver when using internal endpoints such as the internal service IP
      or kubernetes.default.svc. No other usage is guaranteed across distributions
      of Kubernetes clusters.
  creationTimestamp: "2023-04-18T17:37:33Z"
  name: kube-root-ca.crt
  namespace: default
  resourceVersion: "384"
  uid: 73be354c-dd76-4d54-8025-05391b850eef

[poblin-orange]

I guess its a matter of taste. My aim is to avoid inlining the ca cert in the HelmChart CR definition, so a configMap reference would be ok for me :-) Or a local fs path (as i already set up this ca for k3s registry mirror configuration).