caProvider sample

[ctr49]

Describe the bug
caProvider is a supported option besides caBundle to establish the trust between ESO and bitwarden-sdk-server. However, all examples (in the Readme and hack) only use the caBundle.

There has been some discussion in #9 and since then cert-manager also provides a trust-manager to get around some issues.

However the usage of caProvider in this context is not clear to me and trying to use it I receive the following error message from an ExternalSecret CR:

Get "https://bitwarden-sdk-server.external-secrets.svc.cluster.local:9998/rest/api/1/secrets": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "cert-manager-bitwarden-tls")

Manifests:
bitwarden-bootstrap-issuer

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: bitwarden-bootstrap-issuer
spec:
  selfSigned: {}

bitwarden-certificate-issuer

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: bitwarden-certificate-issuer
spec:
  ca:
    secretName: bitwarden-tls-certs

bitwarden-tls-certs

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: bitwarden-tls-certs
  namespace: external-secrets
spec:
  dnsNames:
    - bitwarden-sdk-server.external-secrets.svc.cluster.local
    - external-secrets-bitwarden-sdk-server.external-secrets.svc.cluster.local
    - localhost
  ipAddresses:
    - 127.0.0.1
    - '::1'
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: bitwarden-certificate-issuer
  privateKey:
    algorithm: RSA
    encoding: PKCS8
    size: 2048
  secretName: bitwarden-tls-certs

Then I'm using trust-manager to create a caBundle secret (called ca-bundle-crt) and reflector to copy it into the external-secrets namespace and the following SecretStore:

apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: bw-secret-store
  namespace: external-secrets
spec:
  provider:
    bitwardensecretsmanager:
      apiURL: 'https://api.bitwarden.eu'
      identityURL: 'https://identity.bitwarden.eu'
      auth:
        secretRef:
          credentials:
            key: token
            name: secret-manager-access-token
      bitwardenServerSDKURL: 'https://bitwarden-sdk-server.external-secrets.svc.cluster.local:9998'
      caProvider:
        type: ConfigMap
        name: bw-issuer-public
        namespace: external-secrets
        key: ca-bundle.crt
      organizationID: 'my-org-uuid'
      projectID: 'my-project-uuid'

3. provide the Kubernetes and ESO version
   Kubernetes 1.34
   ESO 1.1.0

Expected behavior
I'd expect ESO to get the Secret from the caProvider and be able to establish a TLS connection to the bitwarden-sdk-server

Btw, if that works (with trust-manager creating a public bundle from the bitwarden-cert-issuer and making that available to ESO) I wouldn't even call it "hack" anymore.

[Skarlso]

Hello.

Interesting. Not sure if that works with the bundle, since it's required to put the right certificate into the right location inside the bitwarden container. 🤔 Are you mounting in the certificate?

[Skarlso]

Also, the configmap value should be pem encoded binary value. Do you have that?

[ctr49]

Yes, but maybe not from the right secret.
Could you please shed some light on the "hack" setup and what the purpose of each cert is? I'm a bit confused about the two instances of bitwarden-tls-certs secrets (in two different namespaces but with the same name) and which is supposed to be used by what.

[Skarlso]

One is the bootstrap certificate that's bitwarden-bootstrap-certificate which lives in the cert-manager namespace that is used as a root certificate for every other certificate. For that bitwarden-tls-certs is created in cert-manager namespace to seed all other certificates. Then a specific certificate with specific dns names is created in the default namespace because that's where the testing infra is deployed into. That's the actual certificate for the server that is being used also in the bitwarden-tls-certs secret but this time in the default namespace where the server is running at and mounted into from.

The root certificate is supposed to be used by cert-manager. The generated certificate in default namespace is supposed to be used by the server being mounted into. That's the self-signed certificate.

You can read more about this on the cert-manager documentation here: https://cert-manager.io/docs/configuration/selfsigned/

[ctr49]

Right, I know the example. It doesn't have any dnsNames nor IP addresses attached (and doesn't need to as it never serves resources but only signs other certs) and it's secret name ("root-secret") can be easily distinguished from any secret names it issues. I have the assumption that due to the same name of the secret and giving the CA dnsNames and ipAddresses some things may get mixed up without noticing, especially when using other namespaces than in the example (i.e. I wouldn't want the bitwarden-sdk-server in the default namespace).

I'm still struggling to get it to work even with the bare caBundle (without my above suggestion to use caProvider and trust-manager). But that's probably worth a separate issue.

[Skarlso]

This is an example:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: bitwarden-secretsmanager
  namespace: external-secrets
spec:
  provider:
    bitwardensecretsmanager:
      apiURL: https://api.bitwarden.com
      identityURL: https://identity.bitwarden.com
      bitwardenServerSDKURL: https://bitwarden-sdk-server.default.svc.cluster.local:9998

      # Use caProvider to reference the ConfigMap containing the CA certificate
      caProvider:
        type: ConfigMap
        name: bitwarden-ca-bundle
        key: ca.crt
        # optional namespace
        # namespace: cert-manager

      auth:
        secretRef:
          credentials:
            name: bitwarden-access-token
            key: token

      organizationID: "your-org-id"
      projectID: "your-project-id"

And then a config map:

# Created by hand, or kubectl:
# kubectl create configmap bitwarden-ca-bundle \
#   --from-file=ca.crt=/path/to/ca.crt \
#   -n external-secrets

apiVersion: v1
kind: ConfigMap
metadata:
  name: bitwarden-ca-bundle
  namespace: external-secrets
data:                                                                                                                    
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    MIIDxxx...your-ca-certificate-here...xxx
    -----END CERTIFICATE-----

I don't know what else there is. :D It's not like it's the purpose of this project how to set up certificates. I'm not an expert on the subject either. But what I have set up locally works this way perfectly so I'm not sure what else there is to do about it, sorry.

If you do figure it out, I would appreciate a documentation change. :)